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ABSTRACT 


Resupplying Marine Corps units ashore from a seabase presents a unique challenge for 
amphibious planners. In particular, it is a laborious process to generate the schedules for 
the ship-to-shore assets that deliver supplies ashore. In this thesis, we focus specifically on 
the delivery of bulk fuel for a Marine Expeditionary Unit (MEU). We introduce the MEU 
Amphibious Connector Scheduler (MACS) tool to quickly provide amphibious planners 
with optimized and executable ship-to-shore delivery schedules of bulk fuel to multiple 
locations ashore. MACS consists of three main models. The first is a dynamic network 
flow model to compute the optimal number of runs (i.e., round-trips) for each delivery 
asset to meet the demand for fuel on shore as quickly as possible. The second model is an 
assignment heuristic that orders the runs for each delivery asset. This assignment heuristic 
allows us to bypass a slow mixed integer linear program. The final model is a linear program 
that takes the output from the first two models and creates a minute-by-minute schedule 
that minimizes the average completion time over the delivery assets. We analyze several 
different scenarios, and MACS generates schedules in less than one minute. 
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Executive Summary 


Planning for amphibious operations is a time-consuming and arduous process due to the 
complexity of tasks, elevated risks, and constraints of ship-to-shore movement. Specif¬ 
ically, current daily planning efforts for sustainment operations of Marine Expeditionary 
Unit (MEU) units ashore are inefficient and overburdened by other concurrent planning 
requirements. This results in inefficient use of air and surface delivery assets, not meet¬ 
ing operational needs, and staff exhaustion. A combination of competing requirements, 
insufficient fuel transport containers, and time-constrained planning factors create a sizable 
problem for planners that must be addressed each day that units are conducting operations 
ashore. 

Scheduling the ship-to-shore movement of people, assets, and resources within a time- 
dependent and constrained environment is frequently the most tedious, time-consuming, 
and complex aspects of the overall plan. The coordination of loading, movement, unloading, 
and docking of multiple, large, powerful ship-to-shore delivery assets (called connectors) 
over the open ocean, between multiple ships and beaches, requires extreme detail and 
diligence. 

This thesis develops the MEU Amphibious Connector Scheduler (MACS) planning tool 
using a multi-model approach to quickly and efficiently develop feasible ship-to-shore 
amphibious schedules to deliver bulk fuel from a seabase. This tool uses reasonable 
planning inputs to develop minute-by-minute schedules of both surface and air amphibious 
connectors. We define amphibious schedules as a collection of connector runs (i.e., round- 
trips) comprising the following six time points: 

1. Eoad at ship 

2. Depart ship 

3. Arrive at beach/landing zone 

4. Unload at beach/landing zone 

5. Depart beach/landing zone 

6. Arrive back to the ship 

MACS easily solves basic and complex MEU resupply scenarios, integrating both surface 
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and air connectors to satisfy fuel demand ashore as quickly as possible. Analytical planning 
tools are increasingly important to amphibious planners because the Marine Corps and 
Navy must continue to progress not only their technologies and tactics, but also their staff 
planning processes to operate in today’s complex and distributed operating environments. 
MACS can significantly reduce the amount of time and staff man-hours necessary to plan 
bulk fuel resupply operations from a seabase. Planning aids such as MACS are critical if 
the Marine Corps wants to remain the premier amphibious force in readiness. 

MACS integrates three separate models using realistic planning inputs. The first model, 
called the Quickest Flow model, is a dynamic network flow model formulated as a linear 
program. The Quickest Flow’s objective is to satisfy demand for fuel ashore as quickly as 
possible. The primary output of the Quickest Flow model is the number of runs for each 
connector type from the seabase to each land node. This information alone is of immense 
value to amphibious planners as they attempt to allocate relatively few connectors across 
multiple different missions to include required maintenance. 

The output from the Quickest Flow model is used by the second model, the Assignment 
Heuristic, to create a “first cut” of the schedule through the use of different assignment 
policies. An example of an assignment policy is the policy that sends the next available 
connector to the land node that has the largest number of scheduled runs remaining. The 
Assignment Heuristic is critical to the practical usability of the overall model. Without 
the Assignment Heuristic, we would need to use a binary mixed integer linear program 
to transform the Quickest Flow model output to the final schedule, which would make it 
difficult to impossible to solve in a reasonable amount of time for many scenarios. 

The final model, the Scheduler Linear Program, is a linear program that takes the output 
from the first two models and creates a minute-by-minute schedule that minimizes the 
average completion time for each connector type. The Scheduler Linear Program accounts 
for potential congestion and smooths out the schedule from the Assignment Heuristic to 
develop the final amphibious schedule. 

We analyze several different MEU-size scenarios, and MACS generates schedules in less 
than one minute. Future work could study larger examples, such as Marine Expeditionary 
Brigade (MEB) scenarios. This thesis only focuses on the delivery of fuel, but the machinery 
developed has the potential to be the foundation for a much more comprehensive amphibious 
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planning tool that incorporates personnel, vehicles, and pallets of equipment. 
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CHAPTER 1: 
Introduction 


The Marine Expeditionary Unit (MEU) remains America’s preeminent force in readiness 
for conflicts virtually anywhere in the world. The MEU and the Amphibious Ready Group 
(ARG) create a highly capable amphibious force able to strike and conduct operations from 
the sea without a land-staging base. The Marine Corps and U.S. Navy call this seabasing. 
Operations conducted from a seabase (ships) to the shore via transport assets—called 
connectors—are known as amphibious operations and are among the most complex and 
challenging within the Department of Defense. 

Planning for amphibious operations is a time-consuming and arduous process due to the 
complexity of tasks, elevated risks, and constraints of ship-to-shore movement. The Marine 
Corps has earned the reputation of world experts in amphibious operations, but the MEU and 
ARG planners can be quickly overwhelmed by the inherent difficulties and staff synergies 
that must be coordinated for even the most basic operations—moving personnel, material, 
and equipment back and forth between the seabase and the shore. This is especially prevalent 
given the current highly complex and demanding distributed operating environments, when 
dealing with sustainment operations for forces ashore. 

Current daily planning efforts for sustainment operations of MEU units ashore are inefficient 
and overburdened by concurrent planning requirements. This results in inefficient use of 
air and surface delivery assets, not meeting operational needs, and staff exhaustion. A 
combination of competing requirements, insufficient fuel transport containers, and time 
constrained planning factors creates a sizable problem for planners that must be addressed 
each day that units are conducting operations ashore. 

Scheduling the ship-to-shore movement of people, assets, and resources within a time 
dependent and constrained environment is frequently the most tedious, time consuming, and 
complex aspects of the overall plan. The coordination of loading, movement, unloading, 
and docking of multiple, large, powerful ship-to-shore connectors over the open ocean, 
between multiple ships and beaches requires extreme detail and diligence regardless of the 
scale or complexity of the overall mission or campaign. 
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The purpose of this thesis is to design a tool to streamline the planning cycle of amphibious 
operations. Specifically, we formulate mathematical models and develop algorithms to 
schedule connectors that transport bulk fuel from ships to shore. We call this tool MEU 
Amphibious Connector Scheduler (MACS), which takes less than one minute to run on a 
personal computer, and creates an effective delivery schedule. MACS dramatically reduces 
the staff planning man-hours and frees up personnel to focus on the next major phase of the 
operation. 

1.1 Motivation of Research 

As a Battalion Landing Team (BET) Operations Officer, personal experience purports 
that (1) the current planning methods for sustainment operations bogs down a MEU/ARG 
staff within two to three days; (2) efficient use of delivery assets (connectors) quickly 
no longer becomes a requirement; (3) MEU/ARG staffs have very few analytic planning 
tools to streamline the process of moving bulk sustainment assets ashore. This last point is 
important as resupply operations are inherently more fixed and require less “operational art” 
compared to more kinetic operations such as raids or assaults. Therefore, a quantitative tool 
would have the greatest positive effect on optimizing the planning process. The motivation 
of this research is furthered discussed in three aspects below. 

1.1.1 Operational Tempo 

The Marine Corps prides itself on maintaining an operational tempo unmatched by other 
services or adversaries. As seen during Operation Iraqi Ereedom, a land-based Marine 
Corps’ operational tempo overwhelmed the Iraqi Army and pushed far ahead of the United 
States Army despite being in the most contested and populated areas. This ability to 
constantly out-cycle adversaries is one of the main ingredients to the success of the Marine 
Corps. Operational tempo becomes incredibly difficult to maintain in an amphibious 
operating environment. 

The complexity, increased risk, finite resources, and command and control challenges of 
amphibious operations can drastically degrade the operational tempo of even the most pro¬ 
ficient units. Very often the time required to develop an executable ship-to-shore movement 
plan affects the operational timeline negatively due to the complexity and completeness 
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required of amphibious operations’ plans. Additionally, the MEU/ARG Team must be able 
to simultaneously plan and execute multiple missions across the range of military operations 
furthering the necessity for comprehensive quantitative planning tools. Tempo is one of the 
main tenets of maneuver warfare that allows a force to take advantage of enemy weaknesses 
vice striking enemy strengths. It is imperative that forces ashore maintain their operational 
speed and momentum by a responsive and efficient seabase. This is especially applicable 
when it comes to fuel sustainment. A seabase that is constantly playing catchup with key 
logistics will inevitably have an adverse effect on overall mission success. Streamlining 
and finding efficiencies within the daily planning cycle in the form of reliable, prudent, 
and efficient analytical planning tools will directly allow the Marine Corps to maintain 
its operational edge and free up planners to focus on planning more decisive actions or 
missions. 

1.1.2 Efficient Use of Assets 

The efficient use of people, assets and resources is a major planning consideration within 
amphibious operations. A MEU/ARG is isolated, serving as a mobile seabase with no 
ground lines of communication for resupply or maintenance capability. Everything used for 
a particular mission originates from the ships in the seabase and must be exercised and used 
in an efficient manner. The only way for amphibious ships to be resupplied while at sea 
is from other ships, which further reinforces the importance of efficiently using resources. 
Waste of fuel and asset usage must be minimized as ships are not privy to ease of resupply 
or almost indefinite storage capability inherent of land bases. Additionally, in an era of 
constrained resources and budgets, the Navy and Marine Corps must continue to find ways 
to reduce waste and find efficiencies. 

1.1.3 Marine Corps Operating Construct 

The Marine Corps Operating Construct (MOC): How an Expeditionary Force Operates in 
the 21st Century published in September 2016 outlines how the Marine Corps will operate, 
fight, and win in 2025 and beyond, as well as shapes the Corps’ actions in designing and 
developing future capabilities and capacity of the future force. It is essentially a document 
to guide the collective efforts of all Marines and Marine Corps equities to ensure the Marine 
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Corps’ future readiness and relevancy. The MOC explains that the 21st century Marine 
Air Ground Task Force (MAGTF) must be able to operate and fight at sea, from the sea, 
and ashore as an integrated part of the larger Naval force as well as Combined/Joint force. 
This guiding document promotes the requirement for the Marine Corps to be the premier 
amphibious force within the Department of Defense. Maximizing the Navy’s ability to create 
rapidly deployable seabases throughout the world is critical to the long-term prospects of 
the Marine Corps [1]. 

This document stresses the Marine Corps’ dedication to be America’s premier amphibious 
force in readiness. This requires the Marine Corps to continue to innovate and develop 
new best practices to maintain its operational edge in not only an amphibious operating 
environment, but in a distributed environment as well. These requirements further reinforce 
the argument for analytical operational planning and scheduling tools to support sustained, 
distributed operations from the sea. 

1.2 Mathematical Approach 

To develop an effective schedule for connectors to ship bulk fuel from ships to shore, we 
break up the process into three separate models. 

1. The first model formulates a dynamic network flow model to compute the optimal 
number of runs (i.e., round-trips) for each connector type in order to meet the demand 
on shore as quickly as possible. This model is formulated as a linear program. 

2. The second model treats each connector type separately and uses a heuristic to produce 
an ordering of runs for each connector type, so as to meet the constraints due to ship 
space and landing spots on shore. 

3. The third model uses the output from the second model to create a minute-by-minute 
schedule that minimizes the mission completion time. This problem is also formulated 
as a linear program. 

Since it is straightforward to enter data to run the model, the end product is an easy-to- 
use tool for any amphibious planner. By formulating the optimization models as linear 
programs, the whole procedure typically takes less than one minute to produce an effective 
schedule on a personal computer, which dramatically reduces the manual planning that 
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often takes up several hours. 


1.3 Related Work 

In order to generate the connector schedule, we first need to determine the number of runs 
(or round-trips) by connector type. To do so, we formulate a dynamic network flow model. 
Most standard network flow models maximize the flow from a source to a sink without a 
time component [2]. Dynamic network flow models add a time component by expanding 
the network and essentially recreating a copy of the network for each time period to examine 
how the flow moves in space and time (see for example [3]). 

Hamacher and Tjandra’s [3] develop a dynamic network flow approach to model large- 
scale evacuation problems. Of particular relevance to our work is the Maximum Dynamic 
Flow problems described in Sections 3-6 in Hamacher and Tjandra [3] that maximizes the 
dynamic flow that reaches a sink over a given time horizon T. We use this model as a starting 
point for determining the number of runs by connector type. Chapter 3 describes this effort 
in detail. 

Dynamic network flow models are popular with evacuation problems due to the emphasis 
on moving quickly through a network. In his thesis, Langford [4] uses a space-time network 
flow representation to examine the evacuation of individuals from a neighborhood in case 
of an emergency. This work solves for evacuation routes and neighborhood clearing times 
if a central authority can effectively dictate the evacuation plan. His thesis focuses on 
minimizing the time required to evacuate neighborhoods via a proposed road network. The 
outputs of this thesis quantify clearing times of the neighborhoods in question. The dynamic 
network flow component of our MACS tool uses a similar methodology to quickly move 
flow through a network. One modeling difference is that our approach puts a flow constraint 
on the nodes, whereas Langford’s work puts a flow constraint on the arcs. Malveo [5] 
examines a similar evacuation setup as Langford [4] and primarily focuses on the impact of 
congestion. That is during a mass evacuation, if the roads are packed with vehicles, then 
the flow rate along the roads will decrease. Malveo [5] handles this by discretizing the 
nonlinear relationship between the number of vehicles on the road and the velocity. Our 
application does not have congestion along arcs during connector transit. However, we do 
account for congestion at nodes when connectors may need to wait for a spot to open before 
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unloading. 


There exists a limited number of articles on mathematical modeling of ship-to-shore opti¬ 
mization in the literature. We next describe the three works most similar to ours. Viado [6] 
develops a mixed integer program that determines the fuel inventory and delivery require¬ 
ments for a MEU. His thesis focuses on minimizing the initial fuel supply that must be 
staged ashore prior to the initiation of operations and a general just-in-time fuel delivery 
schedule. The outputs of this thesis provide an hourly schedule of delivery times to meet 
the forecasted fuel requirements of a large amphibious operation. Our model produces a 
minute-by-minute plan, rather than an hourly plan, and explicitly accounts for potential 
congestion at beaches, landing zones, and ships when multiple connectors are there at the 
same time. 

Ward [7] formulates a mixed integer optimization model to generate schedules of ship- 
to-shore movements from hospital ships during Humanitarian Assistance operations. His 
model has a similar network structure to ours including: dynamic network using discretized 
time periods, transit time on arcs for different connector types, and number of connector 
spots at each node. He approximately accounts for loading and unloading times, but not with 
the fidelity that we do. He focuses on getting personnel ashore (e.g., doctors) to perform 
particular tasks (e.g., operations) and defines cost penalties for missing deadlines and costs 
for using connectors. His objective is to determine a schedule to minimize a weighted cost 
function. The crucial difference between Ward’s work [7] and ours is that we incorporate 
multiple round-trips for each connector; the connectors in Ward’s model are used either 
once or not at all. Determining the total number of round-trips is nontrivial and one of the 
key pieces of our analysis. 

Reitter [8] develops a seabase logistics planning tool. This tool takes in very detailed 
information and primarily focuses on determining sustainment requirements of deployed 
forces ashore. The inputs include which types of units are ashore and what operations these 
units are performing. The sustainment requirement outputs from Reitter’s tool would be 
very useful as an input to our model. We need the fuel demand ashore at various nodes 
and Reitter’s model [8] could provide this. Reitter’s formulation does provide an aircraft 
scheduling algorithm that is similar to an assignment heuristic we develop (the second 
model in Section 1.2). However, our model incorporates both air and surface connectors. 
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accounts for potential congestion during unloading, and models the network structure on 
land. Reitter does not include these aspects in his planning tool. 

Our MACS tool generates a schedule, and there are many algorithms that schedule many 
different types of tasks. Hartman [9] develops a Passengers and Cargo Route Optimization 
Program (PROP) that serves to provide an optimized plan to transport personnel and cargo 
by air for non-combat or non-operational purposes. The PROP is a mixed integer program 
that generates PMC planning solutions while minimizing operating costs, reducing planning 
time, and satisfying all PMC-unique constraints. The output provides takeoff and landing 
times, routes, and the cargo and personnel transported. This model is much different 
from our work in that it accounts only for the assignment of persons to assigned aircraft 
for administrative transport to a network of land nodes without the development of a 
comprehensive amphibious schedule using multiple connectors across a dispersed network 
of multiple ships and beaches/LZs. 

Jacobs [10] develops a tool to assist in building daily flight schedules for training. The tool 
ensures students perform their required training modules and are matched with appropriately 
qualified instructors. The tool is driven by a mixed integer linear program that allows users 
to adjust weights on a value-oriented objective function to help increase the throughput of 
students. The Jacobs tool and our work both have a matching aspect: we match connector 
round-trips to beaches and Jacobs matches students to instructors. However, the context 
and underlying mathematical machinery are much different. 

1.4 Thesis Organization 

Chapter 2 provides background information on amphibious operations. In Chapter 3 we 
describe the three models that construct the MACS tool. Chapter 4 demonstrates the MACS 
tool via a scenario and presents results. We conclude the thesis and suggest future research 
opportunities in Chapter 5. 
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CHAPTER 2: 

Background on Amphibious Operations 


In order to appreciate how this thesis can impact amphibious operations planning, it is es¬ 
sential to have a general understanding of amphibious planning requirements and equipment 
capabilities of the overall amphibious task force. The amphibious task force comprises two 
coequal commands: the Marine Expeditionary Unit (MEU) and the Amphibious Ready 
Group (ARG). The MEU is commanded by a Marine Colonel who is known as the MEU 
Commander, while the ARG is commanded by a Navy Captain who is known as the 
Commander, Amphibious Squadron (COMPHIBRON). The MEU provides the landing 
force (Marines, equipment, trucks, etc.) and the squadron of aircraft. The ARG is com¬ 
prised of Navy amphibious ships and surface connectors to move MEU assets over the water 
to conduct operations ashore. This chapter supplies the readers with a baseline knowledge 
of amphibious planning and assets, most notably what we call connectors, that are covered 
in this thesis. 


2.1 Amphibious Ready Group 

The seabase structure used by the MEU is the Amphibious Ready Group (ARG). The ARG 
consists of three amphibious ships, each with a welldeck capable of housing and launching 
surface connectors and storing the MEU’s equipment. The three classes of ships are the 
Eanding Helicopter Dock (EHD) class, Eanding Ship Dock (ESD) class, and Eanding 
Platform Dock (EPD). The ships also serve as seaborne command and control platforms 
until control can be transferred ashore to Marine Units. [11]. 

2.1.1 ARG Ships 

Landing Helicopter Dock (LHD) Class Ship 

The EHD, seen in Eigure 2.1, serves as the MEU/ARG command ship as well as the main 
rotary wing and fixed wing seabasing platform with over 90% of MEU aircraft capability. 
Eor our model we assume that all air connectors are based on the EHD. The EHD also has 
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a very large well-deek that houses several surfaee eonneetors. The LHD provides the bulk 
of the amphibious foree organie to the MEU [11]. 



Figure 2.1. Landing Helicopter Dock (LHD) Class Ship. Source: [12]. 


Landing Platform Dock (LPD) Class Ship 

The LPD, seen in Figure 2.2 is the seeond largest ship in the ARG behind the LHD and has 
the eapability to provide an alternate eommand and eontrol eapability. The LPD has a mueh 
smaller flight deek that is used mainly for air refueling and easualty evaeuation operations. 
The LPD has a large welldeck that eontains several surface connectors [11]. 



Figure 2.2. Landing Platform Dock (LPD) Class Ship. Source: [13]. 
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Landing Ship Dock (LSD) Class Ship 

The LSD, seen in Figure 2.3 is oldest of the three ARG ship elasses. It has the least air 
eapability in the ARG and houses some surfaee eonneetors. The LSD generally eontains 
mainly MEU logisties equipment [11]. 



Figure 2.3. Landing Ship Dock (LSD) Class Ship. Source: [14]. 


2.2 Amphibious Connectors 

Connectors are the vehicles the Navy and Marines use to move assets, personnel, and 
equipment, from ships to various locations on land. They are generally divided into 
two subgroups: surface and air connectors. The sequencing of the connectors is key to 
an efficient amphibious schedule that satisfies the MEU and ARG Commanders’ daily 
objectives. Most of the planning requirements’ rigor mentioned in Chapter 1 deals with 
developing the offload schedule for all connectors across all ships being used for that 
particular mission. 

Both air and surface connectors require the same general time events on an amphibious 
schedule. These time points are load at ship, depart ship, arrive at beach (or landing zone), 
unload at beach, depart beach, and arrive back at ship. 

2.2.1 Surface Connectors 

The two surface connectors used in this thesis are the Landing Craft Air Cushioned vehicle 
(LCAC) and the Landing Craft Utility (ECU). These are Navy platforms and under the 
command of the Amphibious Squadron (COMPHIBRON). Both platforms provide the 
MEU and ARG with the ability to move vehicles, supplies, and people from ship to shore 
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via movement over the water. While the LCU has the ability to transport twiee as mueh as 
an LCAC, the LCU is mueh slower and has more stringent landing constraints. The LCAC 
carries less, but is substantially faster and is able to hover over the ground, which reduces 
the landing constraints. 


Landing Craft Air Cushioned (LCAC) 

The LCAC is the mainstay of the Navy’s surface connector fleet, and is the main connector- 
type used for moving vehicles and equipment ashore due to its speed and hovercraft capa¬ 
bility. The hovercraft capability enables it to land on a much wider array of beaches than 
the LCU as it is able to hover over the land and is not powered by a traditional subsurface 
propeller [11]. See Figure 2.4: 



(a) LCAC Transporting Supplies. Source: [15]. 



(b) LCAC Unloading at Beach. Source: [16]. 


Figure 2.4. LCACs Transporting Supplies and Equipment 


As displayed in Figure 2.4a, LCACs can travel over the water at speeds up to 50 knots while 
transporting 60 tons of equipment, but these planning factors are subject to sea state, beach 
slope, and the LCACs fuel requirements [17]. Due to the high rate of speed and ability to 
traverse higher waves, equipment must be firmly secured to the deck. This process requires 
time and we account for this loading and securing time in our model. For most of the 
scenarios we use a planning factor of 20-30 minutes for loading at the ship. Each ARC 
generally deploys with 5 LCACs divided over two ships, the LHD (3 LCACs) and LPD (2 
LCACs) [11]. 


12 




Landing Craft Utility (LCU) 

The LCU, seen in Figure 2.5, is a larger, but less eapable landing eraft. It ean transport 
virtually double the weight of the LCAC per run, but is substantially slower and less eapable 
in rougher seas. Additionally, beeause it operates more like a traditional vessel it is mueh 
more restrieted in the beaehes that it is able to land. The slope, grade, and eomposition 
of the beaeh, as well as the tides have more profound impaets to the usability of the LCU 
versus the LCAC. The LCU ean earry up to 120 tons and has a larger area to transport 
equipment. The LCU is also more eapable at transporting personnel [11]. 




(a) LCU Transporting Supplies. Source: [18]. (b) LCU Unloading at Beach. Source: [19]. 

Figure 2.5. LCDs Transporting Supplies and Equipment 

The MEU/ARG generally deploys with two LCUs aboard one of the ships, usually the 
LSD. The LCUs are substantially slower with a eruising speed at between 6-9 knots. Even 
with the inereased lift eapaeity of the ECU, for missions requiring multiple runs, ECACs 
generally provide a greater amount of assets delivered than the ECU over the eourse of a day. 
Speeifioally, for missions requiring multiple ship-to-shore trips, the ECAC speed dominates 
the inereased eapaeity of the ECU. Additionally, the ship must ballast lower for an ECU 
viee an ECAC beeause the ECU operates more like a vessel itself. Due to the substantial 
differenees in speed, beaeh reaehability and time to offload given eapaeity, ECACs and 
ECUs will generally be assigned different beaehes. If ECACs and ECUs do unload at the 
same beaeh, then they will be assigned separate landing spots. 

2.2.2 Air Connectors 

The Marine Corps squadron supplies the assault support aireraft used to move personnel 
and equipment from ship to loeations further inland. The two air eonneetors are the CH-53E 
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Super Stallion and MV-22 Osprey. The CH-53E has superior lift capability with the MV-22 
being much faster. For purposes of fuel delivery, both have the same capability as their 
maximum lift is dictated by the fuel transport container that both use, not the total weight 
of the fuel. The system emplaced in the aircraft to transport bulk fuel is called the Tactical 
Bulk Fuel Delivery System (TBFDS). These are fuel containers placed inside the aircraft 
that have hoses that deploy once the aircraft lands to refuel vehicles. The aircraft has to be 
configured for this mission and thus can only be used for fuel delivery operations for that 
day. The CH-53s and MV-22s are usually all concentrated on the FHD. 

CH-53E Super Stallion 

The CH-53F, seen in Figure 2.6 is the Marine Corps’ heavy lift helicopter with the capability 
to lift in excess of 30,000 pounds. It has a top speed of 170 knots, a cruising speed of 150 
knots, and range of 540 nautical miles [20]. The MFU’s composite squadron deploys with 
four CH-53E’s and are generally all concentrated on one ship (usually FHD). The CH-53E 
is the aircraft of choice for the TBFDS described in Section 2.3. 



(a) CH-53E in Flight. Source: [21], (b) CH-53E's Departing an LHD. Source: [22], 


Figure 2.6. CH-53E Super Stallion 


14 







MV-22 Osprey 

The MV-22 Osprey is the eornerstone of the Marine Corps assault support aireraft. It 
is teehnieally a tilt-rotor aireraft, not a traditional helieopter, and provides signifieantly 
enhaneed operational range and speed. The MV-22 Osprey ean reaeh speeds of up to 320 
knots, generally operates at between 240 to 280 knots, and has a range of up to 1050 miles. 
The Osprey has a max payload eapaeity of 20,000 pounds eompared to more than 30,000 
pounds for the CH-53E [20]. The MEU deploys with twelve ospreys eoneentrated on one 
ship. 




(a) MV-22 in Flight. Source: [23]. 


(b) MV-22's departing an LHD. Source: [24]. 


Figure 2.7. MV-22 Osprey 


15 




2.3 Fuel Containers for Surface and Air Connectors 

Surprisingly, one of the main constraints associated with fuel delivery operations in an 
amphibious operating environment is the lack of bulk fuel delivery storage on both surface 
and air connectors. Surface and air connectors each have specific fuel storage platforms. 
The main platform for surface connectors (LCAC and LCU) is the Six Container (SIXCON) 
fuel storage tank seen in Figures 2.8c and 2.8d. These tanks are emplaced on the Marines’ 
primary supply truck called the Modular Tactical Vehicle Recovery (MTVR). The MTVR 
can carry up to three tanks and fuel pump (similar to gas station nozzle and hose), but 
generally is only outfitted with two for amphibious operations. Each SIXCON contains up 
to 900 gallons of fuel, and the number available for fuel transport on a MEU varies [25]. 

Air connectors (CH-53E and MV-22s) use the TBEDS, seen in Eigures 2.8a and 2.8b. 
These are internally stored 800 gallon tanks that come equipped with their own hoses to 
provide bulk fuel to forward units once on the ground. This long-range bulk fuel resupply 
capability enables the amphibious task force to expand the operating area ashore and support 
distributed operations. Both the CH-53E and the MV-22 are capable of transporting up 
to three TBEDS tanks. However, due to extremely constrained space aboard amphibious 
ships, squadrons generally only embark 2-6 total systems. This constraint was built into the 
model for realism, but can be scaled up to more systems if required. 
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(a) Single Tactical Bulk Fuel Delivery System unit. 

Source: [26]. 



(b) TBFDS in a CFI-53E. Source: [27]. 



(c) USMC SIXCON fuel container. Source: [28]. 


(d) SIXCON on an MTVR. Source: [29]. 


Figure 2.8. Primary USMC Fuel Containers Used on Amphibious Connectors 



2.4 Staff of the Amphibious Task Force 

As previously mentioned the Navy’s amphibious planning entity is the Amphibious 
Squadron (Amphibious Squadron (PHIBRON)) staff. The PHIBRON staff serves as a 
coequal command to the MEU staff and provides the tasking and coordination for each of 
the ARG ships as well as the surface connectors and air command and control that supports 
the Marine Corps’ plan. The lack of a unified commander physically aboard the ARG 
of all personnel and equipment adds a layer of complexity that does not exist outside of 
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amphibious operations. 

The ARG staff is not as large as the MEU staff, and that sometimes serves as a constraint 
in the overall amphibious planning process. The PfflBRON staff and MEU staff are 
responsible for several critical planning documents to include an amphibious schedule that 
is fully nested with the Marines’ landing plan. MEU and ARG planners act as one nested 
planning team for each mission, but much of the planning is conducted in a "stovepipe" 
manner with sync meetings to ensure all facets of the plan are aligned and synchronized. 
This allows planners to focus on their products, but also leads to much longer planning time 
frames [11]. 

2.5 Planning Requirements and Products 

MEU and ARG planners execute two general planning methods-deliberate planning and 
crisis action planning. The latter is also called the Rapid Response Planning Process (R2P2) 
[11]. Eor the purpose of this thesis we will focus on the deliberate planning process even 
though this model has the potential to significantly add value and efficiency to crisis action 
planning. This section serves primarily to introduce the various planning products that can 
either be replaced or significantly streamlined by the model in this thesis. Both the MEU 
and ARG have similar and supporting planning products and outline the execution of a 
particular mission. 

Joint Publication (JP) 3-02 [30] details the steps that amphibious planners need to take prior 
to developing a landing plan as listed below: 

1. As the landing force, the Marines develop a ground scheme of maneuver to execute 
once ashore 

2. Commander, Eanding Eorce (generally the MEU Commander) identifies support re¬ 
quirements and Navy assets needed to flow forces ashore and accomplish the mission. 

3. Commander, Amphibious Task Eorce (ARG Commander) assesses the MEU Com¬ 
mander’s requests and identifies additional Navy assets needed. 

4. Commander, Amphibious Task Eorce requests additional assets from higher authority 
if necessary. 

5. Plans are adjusted to match assets available. 

6. Commander, Amphibious Task Eorce and Commander, Eanding Eorce agree on the 
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final allocation of means (air and surface connectors, additional aircraft, etc.). 

7. Detailed Landing Plan is the developed. 

This is a very involved and systematic process given the coordination, communication, and 
detailed planning required to execute amphibious operations. This thesis provides a means 
to significantly streamline, with a high degree of fidelity, steps 2 through 7. Providing 
the user a final optimized amphibious delivery schedule of fuel given assets available that 
servers as the landing plan [30]. 

Specifically, this thesis presents a tool that will significantly reduce the amount of time 
planners will need to develop operational and executable plans. More importantly this tool 
possesses the ability to provide MEU and ARG planners with a feasible and executable 
ship-to-shore plan in minutes. Allowing planners to quickly transition to refine the plan, 
not spending more time and effort in determining whether or not a plan to move fuel ashore 
is viable. Below we list several specific amphibious planning products outlined in NTTP 
3-02.1M/MCWP 3-31.5 [11] that could be either streamlined or completely replaced by our 
MACS tool. Please see NTTP 3-02.1M/MCWP 3-31.5 [11] for a more detailed description 
of each of these products. 

Amphibious Task Force Commander products (ARG) 

• Landing Craft Employment Plan 

• Debarkation Schedule 

• Approach Schedule 

Landing Force Commander Landing Plan products (MEU) 

• Landing Eorce Landing Plan 

• Landing Craft and Amphibious Vehicle Assignment Table 

• Landing Diagram 

• Landing Lorce Sequence Table 

• Assault Schedule 

• Heliteam Wave and Serial Assignment Table 

• Assault Support Employment and Assault Landing Table 
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CHAPTER 3: 
Mathematical Formulation 


In amphibious operations, a run refers to a round trip by a connector to either a beach 
or Landing Zone (LZ), and then back to the ship. The goal of this thesis is to produce 
a minute-by-minute schedule for connector runs. This section presents the mathematical 
formulation to achieve this goal. Table 3.1 gives a sample of the output, which specifies a 
connector run by 6 time points. 


Ship 

Run 

Destination 

Start 

Load 

Depart 

Ship 

Arrive 

at Beach 

Start 

Unload 

Depart 

Beach 

Arrive 
at Ship 

LHD 

1 

B1 

0.0 

30.0 

100.0 

100.0 

125.0 

195.0 

LHD 

2 

B1 

30.0 

60.0 

130.0 

130.0 

155.0 

225.0 

LHD 

3 

B2 

60.0 

90.0 

180.0 

180.0 

205.0 

295.0 


Table 3.1. Example of an amphibious delivery schedule for LCAC 


We next turn to the inputs required to generate such a schedule. The inputs for this model 
are reasonable, easy to obtain by the planner, and require no pre-calculating or configuring 
on behalf of the planner. The specific planning inputs are covered extensively in Chapter 4, 
but for context we list a few broad examples of the planning inputs below: 

• number of ships in seabase, number of connectors on each ship, number of docking 
spots for each connector type by ship; 

• connector fuel capacity and speed; 

• land network layout (locations of units needing resupply) and distances from the 
ships, number of landing spots at each land node; 

• fuel demand at each location. 

To create an optimized amphibious schedule requires a series of different models. The first 
model, called the Quickest Flow model, is a linear program that produces the overall number 
of runs for each connector type from the seabase to each land node to satisfy the demand. 
For example the Quickest Flow model might specify that we need six LCAC runs to Beach 
A, four LCAC runs to Beach B, and ten MV22 runs to LZl. The output from the Quickest 
Flow model is used by the second model, the Assignment Heuristic, to create a “first cut” 
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of the schedule through the use of different assignment policies. The final model, the 
Scheduler Linear Program, accounts for potential congestion and smooths out the schedule 
from the Assignment Heuristic to develop the final minute-by-minute amphibious schedule. 
The Assignment Heuristic is critical to the practical usability of the overall model. Without 
the Assignment Heuristic, we would need to use a binary mixed integer linear program 
to transform the Quickest Flow model output to the final schedule, which would make it 
difficult to impossible to solve in a reasonable amount of time for many scenarios. 

This chapter covers the formulation of the three main models comprising the MACS tool. 
Figure 3.1 below provides an overview of the overall model in order to build context for 
the reader as they examine the formulation of the main models throughout the rest of this 
chapter. Each section in this chapter treats its given model as a stand-alone entity. Chapter 
4 provides a more detailed explanation of the implementation of the overall program that 
connects all three models, with detailed examples of the inputs and outputs of each step. 


User inputs 

planning 

requirements 



Quickest Flow LP 

Builds allocation of 
runs by connector 
type to each 
beach/LZ lOT 
satisfy demand. 


Schedule defined by 6 time 
points: 

1. Start Load at ship 

2. Depart Ship 

3. Arrive at Beach 

4. Start Unload at Beach 

5. Depart Beach 

6. Arrive back at ship 


-# runs of each 
connector to 
each land node 



Assignment 


Multi-ship 

Heuristic 

-heuristic 

schedule 

Scheduler LP 

Cycles through 

Produces minute- 

different 


by-minute 

assignment policies 


amphibious 

to assign runs 


schedule by 

departing ships to 


connector type by 

each beach run. 


minimizing the 

then back to the 


finish time among 

ship. Replaces a 


all runs. Integrates 

much slower 


the binary variables 

integer program. 


produced by the 

Creates a rough 
schedule 


Heuristic. 


Optimized fuel delivery 
Amphibious Schedule by 
connector type deconflicted 
across all ships and all 
beaches/LZs 



Figure 3.1. MACS Tool Models Overview 
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3.1 Quickest Flow Formulation 

This section presents an optimization model that determines the number of runs by connector 
type needed to accomplish the fuel delivery mission. We focus on minimizing the time 
to deliver all fuel demanded by the land nodes. At a high level this problem relates to 
classic maximum network flow problems [2] as we flow fuel to the land nodes. However, 
there are two key differences: First, we include a time dimension, which standard network 
flow models do not account for. Second, the flow actually happens in discrete runs moving 
back-and-forth between the ship and the land nodes not as a continuous flow. We address 
these differences through the implementation of a dynamic network flow model and an 
approximation of discrete runs via continuous flow. 

We start with a total amount of supply for each connector type at the seabase (ships). The 
model then pushes the flow from the seabase to beaches and landing zones, and then further 
inland via a network flow framework. The main difference between this model and standard 
network flow models is that we add a time dimension. The model specifies the flow on 
an arc (i,j) leaving node i at time period t, Xijj, vice simply Xij. Figure 3.2 illustrates a 
simple network representing these types of problems. 



Figure 3.2. Simple Network with Two Supply Nodes and Five Demand 
Nodes. 


With respect to the specific network architecture, there are two types of nodes: supply nodes 
and demand nodes. Each supply node represents one type of connector, and is indexed by 
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s e S, where S is the set of different connector types. A flow from supply node s represents 
fuel shipped via connector type s, which in this model can be an LCAC, LCU, MV-22, or 
CH-53. We approximate the flow of fuel by aggregating supply over all ships in the seabase 
and all connectors. Each demand node represents one physical location on the shore, and 
is indexed by / E L, where L is the set of demand nodes ashore. A flow into demand node 
I represents fuel delivered to that location. Additionally, like many network flow problems, 
we define a supersink node that accumulates all satisfied demand across all demand nodes. 

This model contains two sets of decision variables. The decision variable A/ yj represents 
fuel flow leaving node i to node j at time t. The output we need for our overall analysis 
is the sea-to-land flow: for s e S. In order to determine the best sea-to-land flow 

we also need to include land-to-land movement for i,j G L) in the Quickest Flow 
model because we want to flow fuel to all demand points as fast as possible. For the simple 
network shown in Figure 3.2 our analysis must account for the land-to-land flow between 
Blue Beach and Node E in order to determine the total flow originating from the FCAC 
supply node. The second decision variable T„ f represents the amount of fuel stored at node 
n at time t before it is shipped somewhere else at a later time period. 

We next introduce the model parameters. The fuel supply available from supply node s is 
written by supplys, for 5 G 5. For example, if we have 5 FCACs across 2 ships then this 
supply represents the total amount of fuel we can push ashore with all 5 FCACs during the 
course of a welldeck crew day. The total demand at demand node I is written by demandi, 
for I £ L. The storage capacity of demand node I is written by storagei, for I e L. The 
amount of fuel/flow we can push out of a given node each time period is limited by the 
connectors we have available at the node, and is denoted by u„. The parameter u„ is the 
maximum amount of flow we can push out of a node each time period and applies to all 
nodes: supply and demand. Whereas supplys only applies to supply nodes and specifies 
the total fuel we can push ashore in a day by connector type. The time to traverse an arc 
from i to j is defined by tauij. The variable A/yj is the flow leaving node i at time t headed 
to node j, and it will arrive at node j at time t -l- tauij. 

Our goal is to flow the fuel to minimize the time to satisfy all demand. To accomplish this, 
we fix the total number of time periods and maximize the amount of fuel demand satisfied 
across all demand points during this time window. If the amount of demand satisfied is 
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the total demand, we are done. Otherwise we inerease the number of time periods and 
repeat the proeess. Thus we solve the problem many times, inereasing the time window 
until all demand is satisfied. The formulation we present below is for only one fixed time 
window. This model is an adaptation of the evacuation models that appear in Sections 3-6 
of Hamacher and Tjandra [3], with a few modifications that we discuss when defining each 
element of the formulation. 

We present the linear program below, and then explain its constraints. 


Indices and Sets 

t G T 
s e S 
I G L 

ss G superSink 
allSinks 
i, j,n£ N 

iUj) 6 ^ 

Data [units] 

maxTime 

Ufi 

tauij 

nodeCapi 
supply s 
demandi 


time periods 
supply nodes 

land nodes that have a fuel demand 

single ss G superSink 

All sink nodes allSinks = L U superSink 

n £ N dX\ nodes in network: A = 5 U allSinks 

arcs directed from node i to node j in N 


total time available for operations [minutes] 

capacity on flow leaving node n, each time period [gallons] 

time to travel on each arc (i,j) [minutes] 

storage capacity at node I [gallons] 

total supply of fuel node [gallons] 

fuel demand at node I [gallons] 


Decision Variables [units] 


Xijj Flow of fuel from i to j starting at time t [gallons] 

y„ f Fuel stored at node n at time period t [gallons] 
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Formulation 


max 

X,Y 

tsT (i,ss)£A 


(3.1) 

S.t. 

7^,0 = supply s 

Ms eS 

(3.2) 


o 

II 

o 

V/ 6 allSinks 

(3.3) 


T/,f < nodeCapi 

Ml eL,\/teT 

(3.4) 


j£N\{ss): 

{n,j)£A 

\/n£N,\/t£T 

(3.5) 


^ ^i,ss,t ^ demandi 

teT 

Ml £L 

(3.6) 


Yn,t+1 — Yfij + ^ ^i,n,t-tauin ~ ^ 

ieN: jeN: 

(i,n)eA (nJ)eA 

\/n£N,\/t£T 

(3.7) 


Yl^maxTime — 0 

Ml eL 

(3.8) 


^ ^ ^ Xs,j,t < ^ demandi 

teT s£S jsN: l£L 

(s,j)£A 


(3.9) 


IV 

o 

\fi e N,\/j eN,\/teT 

(3.10) 


IV 

o 

\/n£N,\/t£T 

(3.11) 


The objective for this model is to maximize the amount of demand satisfied by the end 
of all time periods. Therefore, we track the flow of fuel to the supersink node ss by the 
end of all time periods T. The constraints associated with the quickest flow formulation 
primarily deal with maintaining the balance of flow between nodes over time. Specifically, 
these constraints ensure that for each time point the flow into demand nodes does not exceed 
capacity. 

1. Constraint (3.2) ensures all supply originates at the source nodes 5 6 S at time 0. 

2. Constraint (3.3) initializes the starting supply at the land nodes to zero. 
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3. Constraint (3.4) ensures that the on-hand supply amount stored at each node and at 
each time period is less than the node’s storage capacity. 

4. Constraint (3.5) creates an upperbound for the amount of flow emanating from each 
node at each time period. This constraint ensures that the total outgoing flow from 
each node does not exceed the node’s ability to push fuel out in one time period. 

5. Constraint (3.6) ensures the correct amount of demand is satisfied at each land node. 
This is accomplished through super Sink bookkeeping that requires that the total flow 
going to the super Sink node from each land node does not exceed the node’s demand. 

6 . Constraint (3.7) defines the amount of storage at a node n in a given period in terms 
of the previous storage value and the flow into and out of the node. 

7. Constraint (3.8) ensures that there is not excess fuel stored at any land node at the end 
of the time period of interest. All fuel delivered ashore should be consumed and all 
storage of fuel resides at the seabase via the connector nodes 5. 

8 . Constraint (3.9) has a similar aim to constraint (3.8) in that it ensures that the total 
fuel sent ashore across all supply nodes does not exceed the requirement. 

9. Constraints (3.10) and (3.11) ensure the decision variable values are nonnegative. 

The output from this model that we concern ourselves with is the sea-to-land flow: Xsjj 
for 5 e 5. Specifically, we want the fuel flow from each connector type 5 to each land node 
j over the course of the day 2fer We translate this value into number of runs by 
dividing this total flow over the capacity of a connector type. Thus we now have the total 
number of runs required by connector type that we can assign to specific ships and beaches 
or LZs in the form of a schedule. 

Our model is based on the evacuation models of Hamacher and Tjandra [3]. There are two 
main distinctions with our approach. In the Hamacher and Tjandra model the goal is to 
maximize the number of people evacuated; it does not matter where the evacuees end up. 
In our model this is equivalent to maximizing the total flow of fuel ashore without regard 
to how the fuel is allocated across the demand nodes. In our model we want individual 
demand nodes to receive exactly their fuel demand; no more, no less. We built Constraint 
(3.6) to ensure demand is properly satisfied at each node. Second, we have both a supply 
and a demand that will not match up (demand must not exceed supply), whereas Hamacher 
and Tjandra simply consider the number of people to evacuate, so the supply implicitly 
equals demand. This results in extra bookkeeping constraints such as Constraint (3.9) to 
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ensure the supply sent ashore does not exeeed the demand ashore. 

A downside of this formulation is we have to solve the model repeatedly until all demand is 
satisfied. We eould choose a large time window and maximize a discounted sum of demand 
satisfied by time period. An issue with this formulation is we need to choose a large enough 
time window such that all the flow originating from the supply nodes leaves the seabase 
during this time window. We leave this for future work. 

3.2 Assignment Heuristic 

The Assignment Heuristic described in this section and the Scheduler Linear Program 
described in Section 3.3 only apply to one connector type at a time. We have to re-run 
these two models separately for each connector type to produce the final schedule for each 
connector. The Quickest Flow model in Section 3.1 provides the total number of runs 
from the seabase to each land node by connector type. The next step is to allocate those 
runs across the ships to create a schedule. This requires us to expand our notion of runs. 
We can define runs in terms of the order in which connectors depart the ship or return 
to the ship. For example, the first run from the LHD might be the third run to return to 
the LHD. We can also define runs from the perspective of arrivals to a beach or LZ. For 
multiple ships and multiple beaches and/or LZs we need to associate ship runs with beach 
runs. For example, if the first run from the LHD and the first run from the LSD both are 
going to Beach A, then which arrives to Beach A first? Does the first run of Beach A 
correspond to the first LHD run or the first LSD run? This situation requires an assignment 
to create the proper sequencing of connectors to beach or land nodes. To fully formulate 
this assignment problem of ship runs to beach runs would require assignment variables 
and integer programing. For completeness we present the integer program formulation in 
the Appendix. Even for small examples, the integer program can take hours to solve (if it 
solves at all). Possible follow-on research could focus on improving the integer program 
formulation and performance. 

To solve the task of assigning each departing ship run to each beach run, and then assigning 
each beach run back to a return ship run, we develop a heuristic vice a binary integer program. 
The algorithm essentially tracks what each connector is doing at any given moment. The 
algorithm focuses on each connector and tracks it as it moves back and forth between the 
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ship and land location. The algorithm processes events chronologically associated with 
the connectors. These events include loading at the ship, transiting to land, unloading on 
land, and transiting back to the ship. After processing a specific event for a connector, the 
connector is associated with an updated time and event, and the algorithm continues by 
determining the connector with the next event to process. The algorithm continues until all 
runs at all beaches/LZs have been assigned. We describe the algorithm in this section and 
provide pseudocode in the Appendix. 

The algorithm also tracks pertinent information with respect to each beach/LZ and ship in 
addition to the connector and stores the information in objects. The algorithm then uses 
this information to identify and assign which “event” should be scheduled next with respect 
to the connector. The three variables—namely, connector, beach, and ship—are discussed 
below. 

Connector. The heuristic tracks each connector’s current status. The statuses are generally 
related to components of the current runs, such as loading the ship, unloading at the 
beach/LZ, and transiting. For each connector the algorithm tracks its current status, the 
time associated with the status, the connector ID and its associated ship ID, the current 
departure run, the beach ID and the beach run associated with the current run, and the 
return ship run. There are 4 statuses, described in detail below. 

1. Waiting to load at ship: The time associated with this status is the time the connector 
returns to the ship. At this point the connector is ready and waiting to load. The 
connector is able to load whenever the next loading spot on that ship is available, 
which is tracked via the Ship object. We define a "spot" as a position where the 
connector can load or unload. If the number of spots is less than the number of 
connectors, then not all connectors can load simultaneously. To transition to Status 
2, the connector’s time updates to when the connector finishes loading. 

2. Ready for assignment from ship to beach: The time associated with this status is 
when the connector has finished loading and is prepared to transit to the beach or LZ 
(essentially the result from Status 1). At this point the assignment of the connector to 
a beach/LZ takes place. This requires an assignment policy that sends a connector to 
a beach/LZ, given the current situation. For example, one assignment policy might 
send the connector to the beach/LZ that has the largest number of remaining runs. 
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The assignment policy is a critical part of this algorithm, and we defer additional 
discussion to (Section 3.3.1). For now we take the assignment as given, and we 
transition from Task 2 to Task 3 by updating the time to arrival of the connector to 
the assigned beach. 

3. Waiting to unload at the Beach/LZ: This is the time the connector arrives at the beach 
from Status 2. At that moment, the connector is waiting to unload its cargo. The 
connector will unload once a spot is available. We track when the next spot to unload 
becomes available in the Beach/LZ object. After unloading, the connector transitions 
to Status 4, with an updated time at the completion of unloading. 

4. Return to ship: The time associated with this status is when the connector departs the 
beach immediately after unloading. At this point the connector cycles back to Status 
1, with the corresponding time being the time when the connector arrives back to the 
ship. As the connector finishes Status 4 and transitions to Status 1, it has completed 
an entire run. The algorithm saves the information about this just-completed run 
before updating the connector information for the next run starting with Status 1. 

While the algorithm primarily tracks the connectors making runs back-and-forth between 
ships and beaches, it also tracks some auxiliary information about each ship and beach. This 
auxiliary information is useful in tracking the total number of runs and assigning connectors 
to beaches. A description of the Beach and Ship objects is described as follows: 

Beach. For each beach, we track the total number of runs initiated and completed. The 
difference between the two provides a measure of congestion at the beach and can be used 
in the assignment policy. The algorithm also tracks when each beach spot is next available 
for a new connector to begin unloading. 

Ship. For each ship, we tabulate the number of runs initiated and completed. We also 
track when each spot for loading on the ship is next available for a returning connector. 
This is important in determining when the connectors can begin reloading. For this model, 
connectors always return to the same ship, but can be scheduled to different beaches or LZs 
over multiple runs. 
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3.2.1 Assignment Policies 

The beach assignment component introduced in Status 2 is the key aspect of the heuristic 
and the overall program. The algorithm uses the following assignment policies: 

1. Largest remaining run deficit: This policy tracks the run deficit of each land node and 
assigns the connector to the node with the largest deficit. For example, this policy 
would assign the next LCAC run to the beach node with the largest remaining number 
of connector runs required. 

2. Shortest round trip: This policy focuses on the time it takes based on speed and 
distance for a connector to complete a run. This assigns runs based on how quickly 
the run can be accomplished. 

3. Minimize congestion at each land node: This policy tracks how much congestion is 
currently at each beach/LZ and then assigns the next connector to the beach/LZ with 
the smallest congestion. 

4. Random policy: The policy chooses uniformly at random among the beach nodes 
that still have remaining runs. 

The default policy is the shortest-round trip. However, the heuristic can run each of these 
policies separately and then choose the best one. The shortest round trip policy has the added 
benefit of accounting for potential waiting due to congestion by considering the number of 
connectors already at the beach or in transit, which is tracked by the Beach object. The 
algorithm saves information about each run and builds a preliminary schedule once all the 
runs have been assigned. This preliminary schedule is then used by the Scheduling Linear 
Program (see Section 3.3) to produce the final minute-by-minute schedule. 

Each run can be defined in one of three ways: departure ship run, beach run, and returning 
ship run. The algorithm tracks these three definitions for each run. We next walk through 
a simple example to demonstrate our heuristic. For more details, see the pseudocode in the 
Appendix. For this example, we assume the following: 

• Two ships (A and B) with 1 available spot to load on each ship 

• 3 connectors all of the same type 

• 2 beaches (X and Y) with 1 available spot to unload on each beach 
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Ship Connector ID Status Time Departure Run Return Run Beach ID Beach Run 
A A1 I 0 - _ _ _ 

A A2 I 0 - _ _ _ 

B BI I 0 - _ _ _ 

Table 3.2. Starting Conditions 


A1 and BI are loaded to start with moving to Status 2, A2 has to wait for A1 to depart so 
a spot opens for A2 to start loading. We assume 30 minutes to load on Ship A, 50 minutes 
on ship B. 


Ship 

Connector ID 

Status 

Time 

Departure Run 

Return Run 

Beach ID 

Beach Run 

A 

A1 

2 

30 

- 

- 

- 

- 

A 

A2 

1 

0 

- 

- 

- 

- 

B 

BI 

2 

50 

- 

— 

- 

- 


Table 3.3. After first connector has loaded on each sh 

ip 


A2 next loads (starting at time 30) 





Ship 

Connector ID 

Status 

Time 

Departure Run 

Return Run 

Beach ID 

Beach Run 

A 

A1 

2 

30 

- 

- 

- 

- 

A 

A2 

2 

60 

- 

- 

- 

- 

B 

BI 

2 

50 

— 

__ 

_ 

— 


Table 3.4. All connectors now loaded on ships 


A1 is assigned to beach X, then BI assigned beach Y, then A2 assigned beach Y. Time 
updates to arrival time to beach. It takes 50 minutes from A to X, 40 minutes from A to Y, 
and 60 minutes from B to Y 

Ship Connector ID Status Time Departure Run Return Run Beach ID Beach Run 


A 

A1 

3 

80 

1 

X 

A 

A2 

3 

100 

2 

Y 

B 

BI 

3 

no 

1 

Y 


Table 3.5. All connectors arrive at beaches 


A1 arrives first to X and A2 arrives first to Y (even though A2 left after BI). A1 and A2 
unload and then are ready to head back (Status 4). BI has to wait for A2 to unload. We 
assume 35 minutes to unload at X and 20 minutes to unload at Y 
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Ship 

Connector ID Task 

Time 

Departure Run Return Run 

Beach ID 

Beach Run 

A 

A1 

4 

115 

1 

X 

I 

A 

A2 

4 

120 

2 

Y 

I 

B 

B1 

3 

Table 3.6 

no 

. First 

1 

connectors unload at beaches 

Y 

— 


BI unloads (120-140) and A1 and A2 

arrive back to the seabase. 



Ship 

Connector ID 

Task 

Time 

Departure Run Return Run 

Beach ID 

Beach Run 

A 

A1 

1 

165 

1 

X 

I 

A 

A2 

I 

160 

2 

Y 

I 

B 

Bl 

4 

140 

1 

Y 

2 


Table 3.7. A1 and A2 finish runs, B1 finish unloading at beach 


B1 returns and all three have finished one run. The heuristic saves this information and then 
processes the next run for each connector. Note that none of the three types of runs (ship 
departure run, ship return run, beach run) in Table 3.8 are the same for any connector. 


Ship 

Connector ID 

Task 

Time 

Departure Run 

Return Run 

Beach ID 

Beach Run 

A 

A1 

1 

165 

1 

2 

X 

I 

A 

A2 

1 

160 

2 

1 

Y 

I 

B 

Bl 

1 

200 

1 

1 

Y 

2 


Table 3.8. All three connectors complete first run 


3.3 Scheduler Linear Program 

This section covers the third and final model used to generate the amphibious schedule. As 
with the heuristic in Section 3.2, we run this scheduler separately for each connector type. 
This scheduling program uses parameter inputs provided by the planner and the preliminary 
schedule assignment produced by the assignment heuristic in Section 3.2. This program 
produces an optimized, minute-by-minute schedule of the runs from the ships to each land 
node (beach or landing zone), by connector type. Specifically, the model minimizes the 
average completion time among all runs incorporating the six time points listed below: 


1. Load at ship 

2. Depart ship 

3. Arrive at beach/LZ 
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4. Unload at beach/LZ 

5. Depart beach/LZ 

6. Arrive back to the ship 

These six time points are related by the following rules: 

1. Connector cannot start loading until spot is available. 

2. Connector cannot depart ship until it is loaded. 

3. Connector cannot arrive at the land node until after it departs ship and transits. 

4. Connector cannot unload its cargo until after it arrives at the land node and there is a 
spot available. 

5. Connector cannot depart land node until after it has unloaded its cargo. 

6. A connector cannot return to the ship until after it has completed its transit back to 
the ship. 

The linear program uses four main parameters produced by the two previous models in 
addition to parameters supplied by the planner. 

• runs Beach: The number of runs to each beach by connector type. 

• runsShip: For each ship, the number of runs sent out for each connector type. 

• a: A binary parameter that associates a departure run of a ship with a beach run. This 
can be written as yt,m = 1 if the jth departure run of ship i corresponds to the mth 
run of beach k. Otherwise aijxm = 0. 

• c: A binary parameter that associates a beach run with a returning run of a ship. 
Written as Ck,m,ij = 1 if the mth run of beach k corresponds to the jth returning run 
of ship i. Otherwise Ck,m,i,j = 0. 

The first parameter runsBeach comes directly from the Quickest Flow linear program, 
while the other three are products of the Assignment Heuristic. The parameters a and c 
are critical components of the overall model as they serve as functional replacements for 
assignment decision variables of a binary mixed integer linear program. To illustrate a and 
c, consider the example in Section 3.2.1: 


«41A,1 = «A,2,F,1 = 1,7,2 = 1, 


CX,1,A,2 = CF,1,A,1 = CF,2,B,1 = 1- 
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We provide additional examples of these binary variables in Chapter 4. 

The six time points define the critical events for an amphibious offload schedule and are 
key components to the applicability of this program. The overall goal of this model is 
to minimize the average finish time across all runs of all ships. The formulation for the 
Scheduler LP is as follows. 


Indices and Sets 

s e S 
b£ B 
i 6 7 
rs G Rxs 
rb 6 Ryt 

Data [units] 

numConUs 

runs S hip s 

runsBeachh 

spotsShips 

spotsBeachh 

transTimes,b 

loadTimes 

unloadTimet 

dayLength 

oWSlack 


^s,rs,b,rb 


Cb,rb,s,rs 


ships 

land nodes that can be directly reached by this connector type 

6 time points for each run 

set of runs from each ship 

set of runs from each land node 


number of connectors per ship s 

total number of runs from each ship s 

total number of runs to each land node b 

total number of welldeck or fligthdeck spots for each ship s 

total number of landing spots at each land node b 

transit time from ship s to land node b [minutes] 

time to load connector on ship s [minuets] 

time to unload connector at land node b [minutes] 

day length of welldeck/flight crew day [minutes] 

(on water slack) slack time value to limit time connectors are vulnerable 
waiting to unload. 

Binary parameter that associate ship departure runs with beach runs: 
as,rs,b,rb = 1 if the rs departure run of ship 5 corresponds 
to the rb run of land node b 

Binary parameter that associate beach runs with ship arrival runs : 
Cb,rb,s,rs = 1 if the rb run of land node b corresponds to 
the rs return run of ship s 
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Decision Variables [units] 


^i,s,rs 

Yi,b,rb 

7. 

^i,s,rs 

welldeckStarts 

welldeckEnds 


the time of the /th event of the rs departing run from ship s 
the time of the ith event of the rb run of beaeh b 
the time of the zth event of the rs returning run to ship s 
time to start welldeek/flight deek on ship s 
time to end welldeek/flight deek on ship s 


Formulation 


min 

X,Y,Z, 

welldeckStart, 

welldeckEnd 

S.t. 


seS rseRxs 


(3.12) 

welldeckStarts < Xi^s,rs ^ welldeckEnds 

V/ e /, Vs e S, Vrs e Rxs 

(3.13) 

welldeckEnds — welldeckStarts + day Length 

Vs e 5 

(3.14) 

X 2 ,s,rs ^ + loadTlmes 

Vs 6 S, Vrs e Rxs 

(3.15) 

X^^s^rs — X^^s^rs ^ ^ cis^rs,b,rb^ransTinies^b 

b€B rh€.Ryij 

Vs e S, Vrs e Rxs 

(3.16) 

YA,b,rb ^ ^Xb,rb 

yb e B, Wrb e Ryi, 

(3.17) 

Y5,b,rb ^ Y4^b,rb + unloadTimeb 

yb e B, yrb e Ryt 

(3.18) 

Y^^b,rb — Y^ b,rb ^ ^ ^ ^ (^s,rs,b,rb^^^bl^'YilTlCs^b 

s€S rbeRy/y 

yb e B, yrb e Ryi, 

(3.19) 

X 4 ^s,rs - X 2 ^s,rs ^ onWSlack 



X ^ ^ as^rs,b,rbtransTimes^b 

b€.B rb€.Ryh 

Vs e S, Vrs e Rxs 

(3.20) 

^i,s,rs — —l,.v,r.s' 

yi e /, Vs e S, Vrs e Rxs 

(3.21) 

Y^i,s,rs — Y^i-l,s,rs 

yi e /, Vs e S, Vrs e Rxs 

(3.22) 

Yi^b,rb — Yi-\b,rb 

yi e /, Vfo e B,yrb € Ryb 

(3.23) 

^\,s,rs — ^2,s,rs—spotsShips 

Vs e 5, Vrs e 

(3.24) 

Y4,b,rb — Y^b,rb—spotsBeachij 

Vfo G B, Vrfo G Ryh 

(3.25) 

-^l,5,r5' — ^6,s,rs—numConn^ 

Vs G 5, Vrs G BXi 

(3.26) 

^2,s,rs — -^2,.v,r.v-l 

Vs G 5, Vrs G BXi 

(3.27) 

Y^6,s,rs — ■^6,5, r 5-1 

Vs G 5, Vrs G BXf 

(3.28) 

Y4^b,rb ^ Y4^b,rb-\ 

Vfo G B, yrb G Bj/;, 

(3.29) 

Yi,b,rb = XI XI '^■■‘,rs,b,rbXi,s,rs 

s€S rs€.Rxs 

V/ G /, Vfo G B,yrb € Ryb 

(3.30) 
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^i,s,rs ~ ^ ^ ] ^b,rb,s,rsYi^b,rb 

b€.B b€.Ryij 

V/ e 1,^5 € S, Vrs e Rxs 

(3.31) 

^i,s,rs ^ 0 

V/ e /, Vs e S, Vrs e Rxs 

(3.32) 

^Ub.rb ^ 0 

V/ & I,Mb & B,Mrb ^ Ryt 

(3.33) 

^i,s,rs ^ 0 

Mi e I, Ms e S, Mrs e Rxs 

(3.34) 

welldeckStarts > 0 

MseS 

(3.35) 

welldeckEnds > 0 

MseS 

(3.36) 


The objective function for this model is a minimization of the average time required to 
complete all runs across all ships, as X(,^s,rs specifies the completion time of the run. It is 
straightforward to consider other modifications, such as minimizing the final completion 
run. Most of the constraints associated with the Scheduler Linear Program ensure the correct 
sequencing of ship-to-shore events with respect to the six time points of each connector for 
each run. We explain these constraints below: 

1. Constraints (3.13) and (3.14) ensures that all runs occur within the defined welldeck 
or flightdeck time window. 

2. The next set of constraints ensure the proper ordering of the six time points that define 
the sequence of events for each unique connector run to the land node. 

(a) Constraint (3.15) ensures that each connector does not depart the ship until after 
it is loaded. 

(b) Constraint (3.16) ensures that each connector does not arrive at its assigned 
destination until after it has departed the ship and transited. 

(c) Constraint (3.17) ensures that each connector does not unload its cargo until 
after it has arrived at its destination. 

(d) Constraint (3.18) ensures that each connector does not depart the beach/land 
node until after it has offloaded its cargo. 

(e) Constraint (3.19) ensures that each connector cannot return to the ship until after 
it has departed the beach and transited. 

3. Constraint (3.20) limits the amount of risk associated with connectors sitting idle off 
of the coast, and thus minimizes inefficient congestion. If the slack parameter is 1, 
then that means the commander will not tolerate any idling; increasing it beyond 1 
allows some tolerance for idling and congestion off the beach as the connectors wait 
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to unload. 

4. Constraints (3.21), (3.22), and (3.23) ensure that all six time points maintain the 
proper ordering for each of the decision variables X, Y, Z. 

5. The next subset of constraints connects the various runs to create a fluid and decon- 
flicted schedule. 

(a) Constraint (3.24) dictates that a connector cannot load on a ship until there is a 
spot available on the ship. 

(b) Constraint (3.25) is similar to Constraint (3.24), but with respect to beach or 
landing zone spots. This constraint ensures that connectors cannot occupy beach 
spots to unload until one is available. 

(c) Finally, Constraint (3.26) connects specific-type connectors to each other to 
ensure proper flow and deconfliction of schedule events. More specifically, the 
constraint mandates that a connector cannot start loading until the connector has 
returned from the previous run. 

6. Constraints (3.27), (3.28), and (3.29) mandate that runs need to go in order. 

7. Constraint (3.30) ensures that each departure run from the ship corresponds with 
exactly one run from the beach. Each Y connects with exactly one X. 

8. Finally, Constraint (3.31) associates runs on each beach with the return runs to the 
ships. Each Z connects to exactly one Y. 

9. Constraints (3.32), (3.33), (3.34), (3.35), and (3.36) ensure the decision variables are 
nonnegative. 

In Appendix 1 we formulate the integer program version of this model. The key difference 
is the binary assignment variables a and c are decision variables in the integer program, 
not fixed parameters as they are for the above formulation. In Chapter 4 we provide some 
comparisons of the optimal schedule produced by the integer program and our heuristics 
described in Section 3.2-3.3. However, we primarily focus on the heuristic approach 
presented in this chapter because the integer program becomes computationally intractable 
for larger problems. 
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CHAPTER 4: 

Demonstration and Results 


We use MACS to solve several realistie seenarios. For eaeh seenario, we found an opera¬ 
tionally feasible, exeeutable, and eomplete amphibious sehedule to satisfy the fuel demand 
ashore. We implement MACS in Python. The implementation ineludes the three models 
presented in Chapter 3, handling of input and output, and data parsing and massaging. We 
use Pyomo with a CPLEX solver for the two linear programs: Quiekest Flow and Sehed- 
uler. Pyomo is an optimization modeling language based in Python [31], [32]. The initial 
planning parameters are inputted into MACS via six Comma Separated Values (CSV) files. 
Figure 4.1 graphieally depiets the general progression of the model. 



Figure 4.1. Overall Model Components 


In the next several seetions, we will deseribe how the three models deseribed in Chapter 3 
eonneet from initial inputs to final sehedule output. To aid in this explanation, we will refer 
to a eonerete model, whieh is illustrated in Figure 4.2 . 
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I I Beach 1 
^3 Beach 2 


O Landing spots 

Figure 4.2. Scenario Used for Demonstration and Results 

This scenario has the three standard ships of the ARG (reference Seetion 2.1.1); Two 
beaches: Beach 1 and Beach 2 with Beach 1 having two unloading spots; Two landing 
zones represented by the gray cireles: LZl and LZ2 with a road that conneets Beach 1 to 
LZl, LZ2 is only accessible via aircraft. 

4.1 Initial Planning inputs 

The user inputs required by the model are reasonable planning metrics that any amphibious 
planner would use to formulate a landing plan. These parameters mainly relate to distances, 
fuel demand, supply, and conneetors available for the mission. A detailed explanation of 
the input parameters (contained within CSV files) appears below. 

4.1.1 Connector Information 

The conneetor information required ineludes the conneetor type, eapacity to earry fuel as 
cargo, classification, and average transit speed. These factors can be ehanged based on 
factors such as operational necessity, weather, etc. It is important to reiterate that even 
though we are solely eoncerned about surface/air eonnectors from the seabase to the shore, 
we need land conneetor information (e.g., trucks such as MTVRs) for the Quickest Flow 
model beeause the land eonnectors impact how quickly we ean push fuel to the more inland 
locations. See Figure 4.3 for an example. 
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A 

B 

c 

D 

1 

type 

Icategory capacity 

velocity 

2 

LCAC 

surface 

4 

30 

3 

LCU 

surface 

8 

10 

4 

CH53 

air 

2 

120 

5 

IVIV22 

air 

2 

200 

6 

MTVRl 

land 

2 

20 

7 

MTVR2 

land 

2 

20 


Figure 4.3. Example of Connector-specific Inputs. 


4.1.2 Seabase Information 

Figure 4.4 contains the supply side planning parameters. Each row in the CSV corresponds 
to a different ship in the seabase. The CSV contains the number of connectors by type, 
the number of loading spots for each connector type, and the time it takes to load each 
connector type with fuel. We assume the seabase has an unlimited amount of fuel available 
to transport ashore. In reality the ships in the seabase will themselves need to be replenished 
with fuel periodically. 


A B C D E F G,H I J K|L M 

1 id j lC^ taj CH53 MV22 LCACSpots LCUSpots CH53Spots MV22Spots LCACLoad LCULoad CH53Load MV22Load 

2 LHD 3 0 2 2 1 0 2 2 30 80 20 20 

3 LPD 2 0 0 0 1 0 0 0 30 80 20 20 

4 LSD 0 2 0 0 0 1 0 0 40 40 20 20 


Figure 4.4. Seabase Planning Inputs 


4.1.3 Land Node Inputs 

The planning inputs in Figures 4.5 and 4.6 define the land network of the scenario. Figure 
4.5 presents information about each node in the land network. This node information 
includes the fuel demand, capacity to store fuel, and number of land connectors available. 
This CSV also contains the number of unloading spots and time to unload for each type of 
surface and air connector. This information specifies whether the particular land node is 
accessible to a type of surface or air connector. 
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A 

B 

C , D 

E 



G 

H 

1 

j 

< 

L 

M 

1 

id 

demand 

capacity MTVRl 

MTVR2 


LCACSpots 

LCUSpots 

CH53Spots 

MV22Spots 

LCACUnload 

LCUUnload 

CH53Unload 

MV22Unload 

2 

B1 

30 

100 

2 

2 

2 

0 

0 

0 

25 

0 

25 

25 

3 

B2 

20 

100 

0 

0 

1 

1 

0 

0 

25 

40 

25 

25 

4 

LZl 

20 

100 

2 

2 

0 

0 

2 

2 

0 

0 

25 

25 

5 

LZ2 

8 

100 

0 

0 

0 

0 

2 

2 

0 

0 

25 

25 


Figure 4.5. Land Node Planning Requirements 


4.1.4 Land Arc Inputs 

Figure 4.6 contains the arc information for the land network; we assume the network is a 
directed graph. The land connectors travel on these land arcs delivering fuel between land 
nodes. 



A 

B 

C 

1 

start 

Jend 

distance 

2 

B1 

LZl 

90 

3 

LZl 

B1 

90 


Figure 4.6. Inputs for Ground Transport Capacity Ashore 


4.1.5 Distance Planning Inputs 

To connect the supply nodes to the demand nodes, we need the distances from each of the 
ships to each of the demand nodes. Figure 4.7 presents this information. 



A 

B 

C 

D 

E 

1 


B1 

B2 

LZl 

LZ2 

2 

LHD 

35 

45 

125 

60 

3 

LPD 

30 

40 

120 

55 

4 

LSD 

40 

25 

110 

45 


Figure 4.7. Distance Planning Inputs 


4.1.6 General Parameters 

The final input CSV contains a few general parameters that do not naturally fit within the 
previous categories. The day Length parameter defines the length of time during the day 
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that the welldeck or flightdeck can operate. The Quickest Flow model discretizes time, 
and timeStepsPerHour specifies the number of time periods in an hour; the default is a 15 
minute time period. Finally, in Section 3.2 we list several possible policies that could be 
used in the Assignment Heuristic. In MACS we try several policies and choose the best 
one. The numSchedulesToTest parameter specifies how many policies to consider. 



A 

B 1 

1 

dayLength 

10 

2 

timeStepsPerHour 

4 

3 

numSchedulesToTest 

6 


Figure 4.8. Time-specific Inputs. 


4.2 Quickest Flow Implementation 

MACS first executes the Quickest Flow model described in Chapter 3. This model provides 
us with the number of runs by connector type (e.g., 5 runs of LCACs to Beach 1 and 10 runs 
of MV-22 to LZl). The main inputs to this model are the planning parameters outlined in 
Section 4.1. 

Preprocessing Inputs required by the Quickest Flow Algorithm 

To run Quickest Flow we need all the data defined in the formulation in Chapter 3.1. Some of 
that data comes directly from the CSV inputs presented in Section 4.1. For other parameters, 
we need to perform some additional preprocessing. We describe below how we determine 
each of the Quickest Flow parameters. 

• maxTime: We vary this parameter iteratively until the objective function equals total 
demand: Z/sl demandi 

• Un- This is the amount of fuel we can push out of a node each time period. We define 

Un for each node n e N, but recall that N is the union of all supply nodes S and land 
nodes L. We define separately based on whether n is in S or L. For each supply 
node n e S, Un = ma^r/me • demand node n e L, we compute the round-trip 

time along each outgoing arc for each land connector type using the information in 
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Figures 4.3 and 4.6. Combining this round-trip time with land connector capacity 
in Figure 4.3 and number of land connectors in Figure 4.5 produces a rate per time- 
period that each land connector type can push fuel along one particular arc. Summing 
over all types of land connectors produces the rate at which we can push fuel along 
one particular arc, if all land connectors at the node of interest just travel on that one 
arc. We then average over all outgoing arcs to generate the final value of for n 6 L. 

• tauij: the time to travel along an arc. For a land-to-land arc, the distance along an arc 
comes directly from Figure 4.6. Combining the distance with velocity for each type of 
land connector (see Figure 4.3) produces a travel time along the arc by land connector 
type. We weight these travel times by the number of land connectors of each type at 
the originating node (see Figure 4.5) to determine the final value of tauij. In general 
tauij taujj because tauij depends upon the allocation of land connectors at node 
i and tauj^i depends upon the allocation of land connectors at node j 

For a supply-to-land arc, we have the distance from each ship to the land node from 
Figure 4.7, and we have the velocity for the particular supply-type (i.e., connector) 
from Figure 4.3. This information produces the travel time from each ship to the land 
node. We then weight these travel times by the number of connectors of interest at 
each ship (Figure 4.4) to compute the final value of tauij. 

• supply s'. This is an estimate of total supply we can push ashore during the day 
by connector type. For each ship-to-land connection, we have an estimate of the 
total round trip time for the particular connector type using the information from 
Figures 4.3, 4.4, 4.5, and 4.7. The round-trip time includes transit, loading and 
unloading. Combining round-trip time with connector capacity (Figure 4.3) and 
number of connectors per ship (Figure 4.4) produces an estimate for the total amount 
of fuel we can push to one land node during the day if all connectors run non-stop 
from the seabase to that one land node. The final value of supplys is the maximum 
over all accessible land nodes. 

• nodeCapi'. This parameter comes directly from Figure 4.5 

• demandf. This parameter comes directly from Figure 4.5 

The main outputs from this model are the amount of flow by connector to each location, and 
more importantly, the number of runs by connector type to satisfy the flow demand. MACS 
executes the Quickest Flow model repeatedly, changing the maxTime parameter, until all 
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demand ashore is satisfied. Table 4.1 presents the results of the Quiekest Flow model for 
our baseline seenario presented in Figure 4.2: 


Line 

Connector Type 

Land Node 

Number of Runs 

1 

MV-22 

LZl 

7 

2 

MV-22 

LZ2 

3 

3 

CH-53 

LZl 

4 

4 

CH-53 

LZ2 

2 

5 

LCAC 

B1 

8 

6 

LCAC 

B2 

4 

7 

LCU 

B2 

1 


Table 4.1. Output from Quickest Flow Model for Scenario outlined in Figure 


As an example we inspeet Line 5 from Table 4.1 and see that the model indieates that we 
need eight LCAC runs to B1 (Beach 1) as part of the optimized fuel flow plan. The results 
in Table 4.1 are critical inputs to the Assignment Heuristic. 


4.3 Assignment Heuristic Implementation and Key Out¬ 
puts 

As indicated in Chapter 3 the Assignment Heuristic allocates the runs across the ships to 
create an initial schedule. More specifically, it assigns each departing ship run to a beach 
run, and then assigns each beach run back to a returning ship run. The heuristic produces the 
critical assignment parameters as,rs,b,rb and Cb,rb,s,rs that replace binary decision variables 
of a mixed integer linear program. Recall that as,rs,b,rb = 1 if the rs departure run of ship 5 
corresponds to the rb run of beach b, and Cb,rb,s,rs = 1 if the rb run of beach b corresponds 
to the rs returning run of ship s. For more details on these binary parameters refer to the 
Scheduler Linear Program model in Chapter 3. Below we present the assignment parameters 
produced by the heuristic for the LCAC for the scenario in Figure 4.2. 

The table below shows the non-zero values of as^rs,b,rb for the LCAC requirements for this 
scenario. 

For example. Table 4.2 indicates that the 5th departure run from Ship 1 corresponds to the 
1st beach run from Beach 2. In this particular case both the LHD and LPD send their first 
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Ship ID 

Ship Run 

Beach ID 

Beach Run 

1 

1 

1 

2 

1 

2 

I 

4 

1 

3 

I 

5 

1 

4 

I 

8 

1 

5 

2 

1 

1 

6 

2 

2 

2 

1 

I 

I 

2 

2 

I 

3 

2 

3 

I 

6 

2 

4 

I 

7 

2 

5 

2 

3 

2 

6 

2 

4 


Table 4.2. Assignment Parameter as,rs,b,rb that tracks the departure run of 
a ship-to-beach run for the LCAC for Scenario 4.2 


four runs to Beach 1 and their last two runs to Beach 2. We next present the non-zero values 
of Cb,rb,s,rs for the LCAC. 


Beach ID 

Beach Run 

Ship ID 

Ship Run 

1 

1 

2 

I 

I 

2 

I 

I 

I 

3 

2 

2 

I 

4 

I 

2 

I 

5 

I 

3 

I 

6 

2 

3 

I 

7 

2 

4 

I 

8 

I 

4 

2 

I 

I 

5 

2 

2 

I 

6 

2 

3 

2 

5 

2 

4 

2 

6 


Table 4.3. Assignment Parameter Cb,rb,s,rs that tracks the departure run of 
a beach-to-ship run for the LCAC for Scenario 4.2 


We see in the above two tables that the heuristic assigns the two variables so that each ship 
departure and return run maps to only one beach run. 
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4.4 Scheduler Linear Program and Final Schedule 

The final stage of MACS is the Scheduler Linear Program. Recall that this model produces 
the optimized amphibious schedule incorporating the six time points outlined in Section 
3.3. The output will be an amphibious delivery schedule for each connector deconflicted 
across all ships, beaches, and connectors. Before presenting the final schedule, we discuss 
the inputs to the Scheduler Linear Program. 

Preprocessing Inputs required by the Scheduler Linear Program Algorithm 

To run the Scheduler Linear Program requires specifying the data in the formulation in 
Chapter 3.3. Most of those parameters come directly from the CSV inputs in Figures 
4.3-4.8. However, the following four parameters require some additional preprocessing: 

• runsShips'. The number of runs for each connector type for each ship in the ARC. 
This is a direct output of the Assignment Heuristic. This information can be obtained 
from Table 4.2. 

• runsBeachb'. The number of runs for each connector type to each beach/landing 
zone. This is a direct output of the Quickest Flow model. See Table 4.1. 

• The variable a: Assignment parameter generated by the Assignment Heuristic. See 
Table 4.2. 

• The variable c: Assignment parameter generated by the Assignment Heuristic. See 
Table 4.3. 

We now present the final schedule. For the scenario in Figure 4.2, MACS took less than 40 
seconds to run all three models and generate the schedule for all four connector types. We 
ran MACS on a Lenovo Core i5 laptop with 8 gigabytes of RAM. The schedules produces 
by this model are feasible, executable, and efficient given the initial planning parameters. 
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4.4.1 LCAC Schedule 


Ship 

Run 

Destination 

Start 

Load 

Depart 

Ship 

Arrive 
at Beach 

Start 

Unload 

Depart 

Beach 

Arrive 
at Ship 

LHD 

1 

B1 

0.0 

30.0 

100.0 

100.0 

125.0 

195.0 

LHD 

2 

B1 

30.0 

60.0 

130.0 

130.0 

155.0 

225.0 

LHD 

3 

B1 

60.0 

90.0 

160.0 

160.0 

185.0 

255.0 

LHD 

4 

B1 

195.0 

225.0 

295.0 

295.0 

320.0 

390.0 

LHD 

5 

B2 

225.0 

255.0 

345.0 

345.0 

370.0 

460.0 

LHD 

6 

B2 

255.0 

285.0 

375.0 

375.0 

400.0 

490.0 

LPD 

1 

B1 

0.0 

30.0 

90.0 

90.0 

115.0 

175.0 

LPD 

2 

B1 

30.0 

60.0 

120.0 

120.0 

145.0 

205.0 

LPD 

3 

B1 

175.0 

205.0 

265.0 

265.0 

290.0 

350.0 

LPD 

4 

B1 

205.0 

235.0 

295.0 

295.0 

320.0 

380.0 

LPD 

5 

B2 

350.0 

380.0 

460.0 

460.0 

485.0 

565.0 

LPD 

6 

B2 

380.0 

410.0 

490.0 

490.0 

515.0 

595.0 


Table 4.4. Final LCAC Amphibious Fuel Delivery Schedule 


For this scenario we used a total of five LCACs (three on the LHD and 2 on the LPD). 
With respect to the LCAC schedule there are a few points to highlight: First, the Arrive at 
Beach and Start Unload times are identical meaning that there is no waiting for a landing 
spot. Second, when comparing the Arrive at Beach and the Depart Beach times, we see 
that there will never be more than two connectors (number of spots) on Beach 1 at one 
time. Similarly there will never be more than one connector at Beach 2 at one time. Finally, 
when comparing the Arrive at Ship column and Start Load, we see that a connector cannot 
start loading for its next run until it returns to the ship. This schedule is unique from 
the other three in that it includes multiple ships to multiple beaches. Due to the common 
disposition of connector types to different ARC ships (e.g. MV-22s and CH-53s on LHD), 
they represent schedules comprised of one ship and multiple beaches/LZs. In this example 
both ships send all LCACs only to Beach 1 until all eight of its runs are satisfied, and then 
the operation concludes by sending all runs to Beach 2. 


4.4.2 LCU Schedule 


Ship 

Run 

Destination 

Start 

Load 

Depart 

Ship 

Arrive 
at Beach 

Start 

Unload 

Depart 

Beach 

Arrive 
at ship 

LSD 

1 

B2 

0.0 

40.0 

190.0 

190.0 

230.0 

380.0 


Table 4.5. Final LCU Amphibious Fuel Delivery Schedule 
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4.4.3 MV-22 Schedule 


Ship 

Run 

Destination 

Start 

Load 

Depart 

Ship 

Arrive 

at LZ 

Start 

Unload 

Depart 

LZ 

Arrive 
at Ship 

LHD 

1 

LZl 

0.0 

20.0 

57.5 

57.5 

82.5 

120.0 

LHD 

2 

LZ2 

0.0 

20.0 

38.0 

38.0 

63.0 

81.0 

LHD 

3 

LZ2 

81.0 

101.0 

119.0 

119.0 

144.0 

162.0 

LHD 

4 

LZ2 

120.0 

140.0 

158.0 

158.0 

183.0 

201.0 

LHD 

5 

LZl 

162.0 

182.0 

219.5 

219.5 

244.5 

282.0 

LHD 

6 

LZl 

201.0 

221.0 

258.5 

258.5 

283.5 

321.0 

LHD 

7 

LZl 

282.0 

302.0 

339.5 

339.5 

364.5 

402.0 

LHD 

8 

LZl 

321.0 

341.0 

378.5 

378.5 

403.5 

441.0 

LHD 

9 

LZl 

402.0 

422.0 

459.5 

459.5 

484.5 

522.0 

LHD 

10 

LZl 

441.0 

461.0 

498.5 

498.5 

523.5 

561.0 


Table 4.6. Final MV-22 Amphibious Fuel Delivery Schedule 


This scenario calls for two MV-22s from one ship (LHD) delivering fuel to two different 
LZs. When inspecting the Arrive at Ship and Start Load columns of Lines 1-4 we see that 
one MV-22 performs runs 1 and 4 and the other MV-22 does runs 2 and 3. This occurs 
because LZ2 is much closer than LZl. 


4.4.4 CH-53 Schedule 


Ship 

Run 

Destination 

Start 

Load 

Depart 

Ship 

Arrive 
at LZ 

Start 

Unload 

Depart 

LZ 

Arrive 
at Ship 

LHD 

1 

LZl 

0.0 

20.0 

82.5 

82.5 

107.5 

170.0 

LHD 

2 

LZ2 

0.0 

20.0 

50.0 

50.0 

75.0 

105.0 

LHD 

3 

LZl 

105.0 

125.0 

187.5 

187.5 

212.5 

275.0 

LHD 

4 

LZ2 

170.0 

190.0 

220.0 

220.0 

245.0 

275.0 

LHD 

5 

LZl 

275.0 

295.0 

357.5 

357.5 

382.5 

445.0 

LHD 

6 

LZl 

275.0 

295.0 

357.5 

357.5 

382.5 

445.0 


Table 4.7. Final CFI-53E Amphibious Fuel Delivery Schedule 


The first two runs of both CH-53s follow the same pattern: one run to LZl and one run to 
LZ2. One CH-53 does runs 1 and 4, and the other does runs 2 and 3. They both arrive 
back to the seabase at the same time after these two runs. They then head to LZl in tandem 
(Lines 5 and 6). 


4.5 Objective Value Comparison 

Our objective value in the Scheduler Linear Program is the average completion time across 
all runs. It is straightforward to modify the objective function to handle the maximum 
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completion time. We refer to these measures of effeetiveness as mission eompletion time 
to avoid eonfusion with the time it takes to run the algorithms. Table 4.8 presents both 
the average and maximum mission eompletion time for all four types of eonneetors. For 
the LCACs, the average and maximum are over all runs for both the Landing Helieopter 
Dock (LHD) and Landing Platform Dock (LPD). 


We formulate a Mixed Integer Linear Program (MILP) that treats the binary variables 
as,rs,b,rb and Cb,rb,s,rs as deeision variables and henee bypasses the assignment heuristie. We 
present the full MILP formulation in the Appendix. Table 4.8 also lists the MILP results, 
when the MILP solves within 12 hours. 


Average 

Maximum 

Connector 

MACS 

MILP 

MACS 

MILP 

MV-22 

309.3 

309.3 

561.0 

561.0 

CH-53 

285.83 

285.83 

445.0 

445.0 

LCAC 

357.08 

— 

595.0 

— 

LCU 

380.0 

380.0 

380.0 

380.0 


Table 4.8. Average and Maximum Mission Completion Time (minutes) Com¬ 
parison for the MACS Model vs. MILP Model 


From Table 4.8 we see that the MACS model performs extremely well when eompared to the 
MILP. Furthermore, the MACS model ereates an exeeutable sehedule for all four eonneetor 
types in less than a 40 seeonds. The MACS results for the LCU, MV-22, and CH-53 mateh 
the MILP exaetly. The MILP solves for the LCU and CH-53 sehedule within seeonds, but it 
takes 20 minutes to solve for the MV-22. We provide the MILP with the MACS solution as 
a warm-start. The biggest diserepaney with performanee oeeurs with the LCAC. The MILP 
was unable to solve for the LCAC sehedule after 12 hours. The optimality gap at that point 
was 43% and the best integer solution found up to that point matched the MACS solution. 
This illustrates the utility of MACS. The LCAC requires twelve runs from two different 
ships to two different beaehes; very eommon for a full day of amphibious operations for a 
MEU/ARG. 

When eomparing the run-time performanee of the MACS versus the MILP it should be 
noted that the MACS executes Quiekest Flow, Assignment Heuristie, and the Seheduler 
Linear Program for all four eonneetor types in one exeeution of the MACS tool (all in less 
than 40 seeonds). The MILP run-times quoted above only generate the sehedule for one 
eonneetor type at a time. To run the MILP (that replaees the Assignment Heuristie and 
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Scheduler Linear Program) we still need to first run the Quickest Flow model to determine 
the runs allocation. The MILP times presented above do not account for the additional 
run-time to execute the Quickest Flow. For this scenario the Quickest Flow model runs in 
approximately 10 seconds. 

Both the MACS and MILP model take the number of runs to each beach by connector type 
as input from the Quickest Flow model. Future work could modify Quickest Flow, or the 
Quickest Flow output, to consider other combinations of runs in an effort to generate more 
effective schedules. 


4.6 Connector Usage Analysis 

We now illustrate the utility of using MACS to perform what-if analysis. In particular we 
adjust the number of MV-22s available to perform the mission. This is useful in practice 
because we can see the impact changing connector availability has on the operational 
requirements and feasibility of the other connectors to accomplish the fuel delivery mission. 
This allows MEU and ARC Commanders to better balance the allocation of assets to fuel 
delivery missions versus other missions to support the overall operation. Figure 4.9 shows 
how connector usage varies as we change the number of available MV-22s 


Connector Impact Analysis 


§ 

a 


c 

(S 


s 


20 



- MV-22 

- CH-53E 

- LCAC 

- LCU 


Figure 4.9. Impact on Connector Run Requirements when Adjusting the 
MV-22 Allocation 
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Figure 4.9 provides the following insight: 

• The mission is infeasible when no MV-22s are alloeated to the mission. However if 
we inerease the number of CH-53s from 2 to 3 (keeping MV-22s at 0), the mission is 
feasible. 

• As more MV-22s are alloeated to the mission, CH-53E required runs deerease signif- 
ieantly. 

• When we inerease the alloeation of MV-22s to more than two, the number of LCAC 
runs deereases from 12 runs to 11 runs. This oeeurs beeause it is faster to deliver 
more fuel to LZl via MV-22s and then transport fuel to Beaeh 1 via ground assets. 
LZl has four trueks available to transport fuel (See Figure 4.5). 

Objective Value Impact 

We next analyze the impaet on the average and maximum mission eompletion time as we 
vary the MV-22 alloeation. The two graphs eomprising Figure 4.10 illustrate the effeets. 



Max Completion Time 



1 2 3 4 5 

Available MV-22s 


MV-22 

CH-53E 

LCAC 

LCU 


(a) Average Mission Completion Time 


(b) Maximum Mission Completion Time 


Figure 4.10. Average and Maximum Mission Completion Times when varying 
allocation of MV-22s 


We see in Figure 4.10a that the average mission eompletion time for CH-53Es deereases 
signifieantly due the alloeation of additional faster aireraft (MV-22) and less required runs 
from the CH-53E. The worst-ease average mission eompletion times eorresponds to the 
ECU in all eases. 
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In Figure 4.10b we witness a signifieant reduetion in the maximum mission eompletion 
time of the CH-53E for the same reasons discussed above. The maximum time for the 
MV-22 increases as we move from one to three MV-22s, but then decreases significantly 
thereafter. This illustrates how the speed of the MV-22 can impact the overall mission 
timeline. Eventually, with enough MV-22s we can deliver the fuel very quickly. 

In both figures we see that when the MV-22 allocation is reduced to one aircraft it has the 
most impact on CH-53s and the ECU mission completion times, especially the maximum 
mission completion time for the CH-53s. 

Placing information such as this in the hands of amphibious planners and decision makers 
is incredibly valuable as there is a constant struggle for the allocation of connector assets 
in an amphibious Marine Air Ground Task Eorce (MAGTE). Decision makers can see the 
impact one or two more connectors can have on the mission. 
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CHAPTER 5: 
Conclusions 


5.1 Summary 

This thesis develops a suite of interconnected models called MACS that produces a feasible 
and executable ship-to-shore amphibious schedule for fuel delivery operations. MACS 
integrates both air and surface connectors and accounts for potential congestion at loading 
and unloading sites. In the scenarios we consider, the entire process runs in under 40 
seconds. Experience shows that this tool has the potential to significantly improve the 
planning process to efficiently deliver bulk fuel to units ashore to maintain operational 
tempo. 

Through the use of a dynamic network flow model based on mission specific planner 
inputs, the Quickest Flow model effectively provides planners with the number of required 
runs by connector type that satisfy demand within the time allotted. This information 
by itself provides significant support to decision makers. The Assignment Heuristic uses 
assignment policies to quickly produce assignment parameters that allow us to bypass the 
use of a slow mixed integer linear program. Finally, the Scheduler Finear Program integrates 
the assignment parameters to incorporate the six time points that define any amphibious 
schedule. 

To date, this model has easily constructed schedules for several different MEU fuel resupply 
scenarios that includes preliminary testing of a larger scenario (6 ships in ARG) with a 
much more diverse and complex network of resupply locations ashore. In future work, we 
plan to perform more testing on larger scenarios (see Section 5.2). When compared to the 
MIFP formulation in Appendix 1, the MACS tool is able to solve all scenarios quickly with 
the MIFP unable to fully develop connector schedules for scenarios requiring more than 
approximately 10 runs in a reasonable amount of time. 
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5.2 Future Research 


5.2.1 Model Improvements 

Exploring algorithmic improvements to the three underlying models comprising the MACS 
tool and/or the MILP could further enhance the speed and performance of the tool. This is 
especially important as we use MACS to execute more complex and demanding scenarios. 
It may be possible to improve the MILP performance by incorporating additional constraints 
on the binary assignment variables a and c. While it is doubtful that the MILP would be 
able to scale to very large scenarios, it is important to compare our heuristic performance 
to the optimal when possible. 

Currently we consider four assignment policies in the Assignment Heuristic (see Chapter 
3.2.1). One could define additional policies or tweak the existing policies to improve the 
Assignment Heuristic. The Quickest Plow model is arguably the most important component 
of our algorithm, so improving that model has potential to make a significant impact. We 
could consider slight variants of the current output from Quickest Plow. Lor example we 
could increase or decrease the number of runs for each connector by one. Another option 
would modify the objective function in Quickest Plow. Currently we run Quickest Plow 
many times to determine the minimum time to deliver all the fuel. We could instead use 
a weighted discounted average as our objective function to reduce the number of iterations 
while still ensuring fuel is delivered quickly. Por the Scheduler Linear Program, we could 
add additional constraints to make the schedule more operationally relevance. Por example 
aircraft almost always travel to and from land nodes in tandem, and thus we should have a 
constraint to force this into the schedule. 

5.2.2 Apply to All Personnel and Equipment in a MAGTF 

This thesis presents the tool for scheduling bulk fuel resupply to units ashore, but possesses 
the speed and functionality to be the foundation for a much more comprehensive amphibious 
planning tool. This tool would be able to optimize and schedule ship-to-shore movement 
of all equipment and personnel organic to a MEU. This would revolutionize how the 
Marines and Navy plan for amphibious operations, and significantly reduce the planning 
cycle required to provide key decision makers with viable amphibious plans from which to 
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choose. To start with, we could divide connector cargo into a limited number of categories 
such as fuel, personnel, vehicles, and pallets of equipment. It no longer suffices to merely 
specify when each connector leaves the seabase. We now need to also determine what 
material is on each connector. One possibility is to expand the Quickest Flow model to a 
multi-commodity flow variant. Efforts are currently underway to expand the capabilities of 
the model to develop a comprehensive amphibious planning tool. 

5.2.3 Stress MACS Against Larger and More Complex Scenarios 

We have conducted very preliminary testing of the MACS tool with a larger amphibious 
force (essentially a scenario that includes 2 MEUs). The next step after codifying the 
tool’s performance against the 2-MEU model would be to apply this model to a Marine 
Expeditionary Brigade (MEB) sized scenario. The MEB and associated amphibious task 
force is significantly larger than a MEU, and would be a good test for the model. There are 
several Marine Corps schools and courses that have well thought-out and comprehensive 
scenarios that take planners days to plan bulk fuel resupply. We believe the MACS tool 
would demonstrate its full potential as a highly effective and efficient planning tool for larger 
amphibious forces. Additionally, integrating the Maritime Prepositioning Eorce (MPE) 
assets into the tool would further display the flexibility of the MACS. 

5.2.4 Integrate Future Combat Ship-to-Shore Systems 

The Marine Corps is currently experimenting with new technologies that could be integrated 
into the MACS model. Unmanned logistics systems such as the K-MAX vertical lift 
platform could immediately be introduced into the tool to determine its overall impact on 
fuel delivery operations in an amphibious environment. Additionally, the CH-53K would 
be another interesting platform to introduce into the MACS tool to see how its added lift 
capacity, speed, and capability will enhance amphibious operations as it begins to replace 
older CH-53E models. 
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APPENDIX A: 

Mixed Integer Linear Program 


In this appendix, we present the formulation of a mixed integer linear program (MILP) 
that we use as a comparative tool to assess the optimality performance of the Assignment 
Heuristic and Scheduler Linear Program from Chapters 3.2-3.3. The key difference between 
the MILP and the Scheduler Linear Program is that in the MILP as,rs,b,rb and Cb,rb,s,rs are 
binary assignment decision variables, whereas in the Scheduler Linear Program they are 
fixed parameters. The Assignment Heuristic generates as^rs,b,rb and Cb,rb,s,rs for the Scheduler 
Linear Program. Recall that as,rs,b,rb assigns departure ship runs to beach runs and Cb,rb,s,rs 
assigns beach runs to returning ship runs. The MILP can generate the optimal schedule 
very quickly for a small number of total runs (~ 5). However, even for small scenarios (like 
the one presented in Chapter 4), the number of runs can easily exceed 20, and the MILP 
cannot solve in a reasonable amount of time. 

The MILP formulation is nearly identical to the Scheduler Linear Program in Chapter 3 
with the exception of the added binary decision variables. We also need to add a few 
other parameters and variables for bookkeeping purposes and because we need to linearize 
constraints. 


Indices and Sets 

s e S 
b£ B 
i 6 7 
rs G Rxs 
rb e Ryb 

Data [units] 

numConris 

maxRuns 

runsBeachb 

spotsShips 


ships 

land nodes that can be directly reached by this connector type 
6 time points for each run 

set of runs from each ship, cardinality specified by maxRuns 
set of runs from each land node 


number of connectors per ship s 

maximum runs from each ship: Yib£B runsBeachb 

total number of runs to each land node b 

total number of welldeck or flightdeck spots for each ship s 
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spotsBeachh 

transTimes,b 

loadTimes 

unloadTimet 

dayLength 

onWSlack 

M 


total number of landing spots at each land node b 
transit time from ship s to land node b [minutes] 
time to load connector on ship s [minutes] 
time to unload connector at land node I [minutes] 
length of welldeck/fiight crew day [minutes] 

slack time value to limit time connectors are vulnerable waiting to unload 
Bookkeeping variable to linearize constraints: dayLength x {numShips + 1) 


Binary Integer Decision Variables 


as,rs,b,rb Binary variable that associate ship departure runs with beach runs: 

iis,rs,b,rb = 1 if the rs departure run of ship 5 corresponds 
to the rb run of land node b 

Cb,rb,s,rs Binary variable that associate beach runs with ship arrival runs : 

Cb,rb,s,rs = 1 if the rb run of land node b corresponds to 
the rs return run of ship s 

Continuous Decision Variables [units] 


^i,s,rs 

Yi^b,rb 

7. 

^i,s,rs 

welldeckStarts 

welldeckEnds 

^^i,s,rs,b,rb 
Y Ci^b,rb,s,rs 


the time of the zth event of the rs departing run from ship s [minutes] 
the time of the zth event of the rb run of beach b [minutes] 
the time of the zth event of the rs returning run to ship s [minutes] 
time to start welldeck/fiight deck on ship s [minutes] 
time to end welldeck/fiight deck on ship s [minutes] 

New variable to linearize problem defined as Xbs,rs x cis,rs,b,rb [minutes] 
New variable to linearize problem defined as Yi^b,rb x Cb,rb,s,rs [minutes] 


Formulation 


min 

x,y,z, 

welldeckStart, 

welldeckEnd, 

Xa,Yc 

a,c 

Z Z 

s€.S rs^Rx^ 


(A.l) 

S.t. 

welldeckStarts < Xi^s.rs ^ welldeckEnds 

V/ 6 /, Vs 6 S, Vrs e Rxs 

(A.2) 


welldeckEnds — welldeckStarts + dayLength 

Vs e 5 

(A.3) 


X2,s,rs ^ + loadTlmes x ^ ^ as,rs,b,rb 

b€B rb€Ryiy 

Vs e 5, Vrs e Rxs 

(A.4) 
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^3,s,rs ^ ^2,s,rs + ^ ^ Os,rs,h,rh X tV ansT ime S G S,VrS G RXs 
b€.B rb€.Ryi, 

(A.5) 

^ ^\b,rb 

yb G B, Wrb G Bj/i, 

(A.6) 

^ 5 ,b,rb ^ i^ 4 ,fo,rZ 7 + unloadTimet, 

Vfe G B, Mrb G Bj/i, 

(A.7) 

^6,b,rb — Y^jy ylf + ^ ^ ^ ^ ^s,rs,b,rb ^ tVQTlsTilTlCs^b 

s€.S rs€.Rxs 

V/j G B, Wrb G Bj/b 

(A.8) 

- ^%s^rs ^ OuWSlack 



X ^ ^ a,,^rs,b,rbtransTimes,b 

b€B rb€.Ryh 

Vs G S, Vrs G Rxs 

(A.9) 

^i,s,rs — —l,.s',r.s' 

Vi G /, Vs G B, Vrs G Bx .5 

(A.IO) 

^i,s,rs — 

Vi G /, Vs G B, Vrs G BXi 

(A.ll) 

^i,b,rb — 

Vi G /,Vfo G B,yrb & Ryb 

(A.12) 

-^l,.s',r5 — ^2,s,rs—spotsShips 

Vs G B, Vrs G Bx^ 

(A. 13) 

^4,b,rb — ^5,b,rb—spotsBeachh 

Vfe G B, Wrb G Bi/fo 

(A. 14) 

-^l,.s',r5' — ^6,s,rs—numConn^ 

Vs G B, Vrs G BXi 

(A.15) 

^2,s,rs — ^2,s,rs-\ 

Vs G B, Vrs G BXf 

(A. 16) 

^6,s,rs — ■^6,5,r5-l 

Vs G B, Vrs G Bx., 

(A.17) 


Vfo G B, Vrfo G Ryb 

(A. 18) 

^i,b,rb ~ ^ ^ ^ ^ ^^i,s,rs,b,rb 

5€S rs€.Rxs 

Vi e I,yb e B,yrb & Ryb 

(A.19) 

^^i,s,rs,b,rb — ^s,rs,b,rb ^ ^ 

V/ e I,ys € S, Vrs G Bx^ 



Vfe G B, Vrfo G Ryb 

(A.20) 

^^i,s,rs,b,rb — ^i,s,rs “ (1 “ ^s,rs,b,rb^ X Af 

V/ G /, Vs G B, Vrs G Bx .5 



Vfo G B, Vrfo G Bj/fo 

(A.21) 

^^i,s,rs,b,rb — ^i,s,rs 

V/ G /, Vs G B, Vrs G Bx .5 



yb G B, Vrfo G Ryb 

(A.22) 

/7€B rb€.Ryiy 

Vs G B, Vrs G Bx^ 

(A.23) 

^ ^ ] ^s,rs,b,rb ~ 1 

5 €5 rs^Rxs 

Vfo G B, yrb G Bj/fo 

(A.24) 

^ ^ ^ ^ ^s,rs,b,rb — ^ ^ ^ ^ l,Z7,rZ7 

b€.B rb€.Ryfy b€.B rb&Ryt, 

Vs G B, Vrs G BXi 

(A.25) 

^i,s,rs ~ ^ ^ ^ ] ^^i,b,rb,s,rs 

b€.B rb€.Ryij 

V/ G /, Vs G B, Vrs G Bx .5 

(A.26) 

^Ci,b,rb,s,rs — Cb,rb,s,rs X Af 

V/ G /,Vfo G B,yrb G. Ryb 



Vs G B, Vrs G BXi 

(A.27) 
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^^i,b,rb,s,rs — ^i^b,rb “ (1 “ ^b,rb,s,rs^ ^ ^ 

V/ e I,Vb e B,Vrb € Ryi, 



Vs e 5, Vrs e Rxs 

(A.28) 

^^i,b,rb,s,rs — ^i,b,rb 

V/ e I,yb e B,Wrb & Ryb 



Vs e 5, Vrs e Rxs 

(A.29) 

^ ^ ] ^b,rb,s,rs ~ 1 

s€.S rs€.Rxs 

yb e B, Mrb e Ryy 

(A.30) 

^ ^ ^ ] ^b,rb,s,rs ^ 1 

b€.B rb€.Ryfy 

Vs e S,yrs e Rxs 

(A.31) 

^ ] ^b,rb,s,rs ~ ^ ] ^s,rs,b,rb 

rs€.Rxs rs&Rxs 

Vs e S,yb & B,yrb 6 Ryb 

(A.32) 

^ ^ ^ ] ^b,rb,s,rs — ^ ^ ^ ^b,rb,s,rs—\ 

b€B rb€Ryiy b€.B rb€Ryh 

Vs & S,yb & B,yrb e Ryb 

(A.33) 

Xi,s,rs > 0 

V/ e /, Vs e S, Vrs e Rxs 

(A.34) 

O 

Al 

Si.. 

V/ 6 /,Vfo e B,yrb & Ryb 

(A.35) 

Xi^s,rs ^ 0 

V/ e I,ys € S, Vrs e Rxs 

(A.36) 

welldeckStarts > 0 

Wse S 

(A.37) 

welldeckEnds > 0 

Vs e 5 

(A.38) 

Xcii^s,rs,b,rb — ^ 

Vi e /, Vs e iS, Vrs e 



Vfo e B, Vrfo e Bj/j, 

(A.39) 

^^i,b,rb,s,rs — ^ 

V/ e /,Vfe e B,yrb & Ryb 



Vs e S,yrs e Bx., 

(A.40) 

^s,T's,b,'rb ^ 

Vs e B, Vrs e Bx^ 



Vfe e B, Wrb e Bj/j, 

(A.41) 

^b,rb,s,rs ^ {0? 1} 

Vfo 6 B, Vrfo e Ryb 



Vs e B, Vrs 6 Bx^ 

(A.42) 


In the Scheduler Linear Program in Section 3.3 we know how many runs originate from 
each ship, and therefore Rxs is an input. In the MILP, the algorithm determines the number 
of runs by ship, and thus we must be careful in how we define Rxs. We do know the total 
number of runs that must originate from the seabase, maxRuns, and thus in the MILP we 
schedule maxRuns runs for each ship: = maxRuns for all s. This results in many 

more runs than are actually required, but provides no restrictions on the number of runs 
from any given ship. This approach produces phantom runs. For example if there are two 
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ships and maxRuns = 10, then the MILP sehedules 20 total runs (10 for eaeh ship), even 
though only 10 runs are needed. The extra 10 runs are phantom runs. The MILP might 
determine to send 4 (aetual) runs from Ship 1, whieh results in 6 phantom runs from Ship 

1. We define the MILP sueh that Xi^s,rs = 0 for all rs eorresponding to phantom runs. 

The objeetive funetion and Constraints (A.2) through (A. 18) are identieal to the formulation 
in Seetion 3.3. The added eonstraints to this model mainly deal with linearizing the new 
deeision variables Xai^s,rs,b,rb and Yci^b,rb,s,rs- We also have some additional bookkeeping 
eonstraints for the binary deeision variables. We explain the new constraints below: 

1. Constraint (A. 19) corresponds to Constraint (3.30), but uses the linearized variable 
Xabs,rs,b,rb- The constraint connects the X variables with the Y variables. 

2. With the MILP we use Xabs,rs,b,rb to avoid having a product of a binary variable and 
a continuous variable. To eliminate this product requires a linearization via a set of 
constraints. Constraints (A.20), (A.21), and (A.22) perform this linearization using 
the standard approach. 

3. Constraint (A.23) ensures that each departure ship run goes to at most one beach run. 
This is an inequality because phantom runs are not assigned to a beach run. 

4. Constraint (A.24) ensures that each run on the beach has to align with exactly one 
departure ship run. This is an equality because each beach run must be satisfied by a 
ship run. 

5. Constraint (A.25) handles the phantom run issue discussed earlier. All phantom runs 
are assigned to smaller indices for rs, thus ensuring the X and Z variables are 0 for 
phantom runs. The later rs indices correspond to actual runs. 

6. Constraint (A.26) corresponds to Constraint (3.31) , but uses the linearized variable 
YCbb,rb,s,rs- Thc Constraint connects the Y variables with the Z variables. 

7. Constraints (A.27), (A.28), and (A.29) perform the same linearization operation as 
Constraints (A.20), (A.21), and (A.22) to linearize the Ycbb,rb,s,rs variables. 

8. Constraint (A.30) ensures that exactly one beach run associates with exactly one 
returning ship run. 

9. Constraint (A.31) ensures that each returning ship run can be assigned at most one 
beach run. The inequality results from the phantom run approach. 

10. Constraint (A.32) connects a to c in that the number of departure runs assigned from 
ship to beach must match the number of return runs-that is A to T via a must match 
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y to Z via c. 

11. Constraint (A.33) is similar to Constraint (A.25) in that the phantom runs returning 
occur for the first indices. 

12. Constraints (A.34), (A.35), (A.36), (A.37), (A.38), (A.39), and (A.40) ensure the 
decision variables are nonnegative. 

13. Constraints (A.41) and (A.42) mandate that a and c are binary variables. 

We use the values of as,rs,b,rb and Cb,rb,s,rs generated by the Assignment Heuristic to warm- 
start the MILP. The warm-start quickly produces a feasible solution that often is near-optimal 
for the scenarios we have studied. 
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APPENDIX B: 

Assignment Heuristic Pseudocode 


In this appendix, we provide the pseudocode for the assignment heuristic. We only present 
the assignment policy for the largest runs deficit. That is we compare the required number 
of runs to each beach/LZ and the number already assigned and then choose the land node 
with the largest difference between the two. For a copy of the actual code, please contact 
Michael Atkinson (mpatkinsOnps. edu) or Kyle Lin (kylinOnps. edu). 


1; function run_assignment_heuristic 
2: b_runs <— get_beach_runs 

3: num_con get_num_connectors 

4; sb_load <— GET_SEABASE_LOADTIME 

5: sb_sp0ts <— GET_SEABASE_SPOTS 

6: b_unload <— get_beach_unloadtime 

7: b_SpOtS GET_BEACH_SPOTS 

8: trav_time get_travel_time 


> From Quickest Flow 

> From Input CSVs 

> From Input CSVs 

> From Input CSVs 

> From Input CSVs 

> From Input CSVs 

> From Input CSVs 


9: sb_obj iNiT_SEABASEOBj(5Z?_5pot5, num_con) > Tracks info about each ship 

10; beach_obj <— iNiT_BEACHOBj(Z?_5pot5) > Tracks info about each beach 

11: conn_pq <— iNiT_coNNECTORs(nMm_con) > Tracks connector info in Priority Q 


12 : 

13: while runs remain do 

14: next_event = conn_pq.get() > Pull next connector event from Pri Q 

15: proc_next_event(b_runs,next_event,sb_load ,b_unload,b_spots, 

trav_time,beach_obj s, sb_obj) 

16: conn_pq.get().put(next_event) > Put updated connector info back to Pri Q 

17: end while 

18; end function 
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> Store info on each ship 


19; function imT_SEABASEOB3(sb_spots, num_con) 
20; sb_obj = [] 

21 ; 

22; for i in l:num_ships do 


23; sb_obj{i] <— [/, 1,(1 

24; end for 

25; rtinm sb_obi 

26; end function 

27; function INIT_BEACHOBj(Z?_5pOi5) 

28; beach_obj = [] > Store info on each beach 

29; 

30; for i in l:num_beaches do 

> First element beach id 
> 2nd element is next run to arrive to beach 
> 3rd element is the next time a spot is available to unload 
> 4th element is number connectors in transit or offloading at beach 
> 5th element is number connectors already assigned to beach 
31; beach_obj[i] <— [z, 1,0,0,0] 

32; end for 

33; return beach_obj 

34; end function 


> First element ship id 
> 2nd element is next run to depart 
> 3rd element is next run to arrive 
> 4th element is the next time a spot is available to load 
- num_con[i]), 0] 
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35; function iNiT_coNNECTORs(nMm_con) 

36: conn_pq = Init_PriorityQueue > Store connector info in Priority Queue 

37: 

38: for i in l:num_ships do 

39; cur_num num_con\i\ > Number of connectors on Ship i 

40: 

41: for j in l:cur_num do 


> 1st element: Time associated with current task 

> 2nd element: current task 

> 3rd element: ship ID 

> 4th element: connector ID 
> 5th element: departure ship run 

> 6th element: beach ID for this run 
> 7th element: beach run 
> 8th element: return ship run 

42: con_info <— [0,1, i,], -1, -1, -1, -1] 

43: conn_pq.put(con_/n/o) > Put connector info into Priority Queue 

44; end for 

45; end for 

46; return conn_pq 

47; end function 
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48; function PROC_NEXT_EVENT(Z?_rMn5, next_event, sb_load, bjunload, b_spots, travjime) 
beach_obj, sb_obj > Additional function inputs 

49: cur_task next_event\l\ > 2nd element in eonneetor info list 

50; 

51: if cur_task == 1 then 

52: prooess_sb_event(nca:i_ceeni, sb_load, sb_obj) 

53: else if curjask == 2 then 

54: process_b_assignment(Z?_rMn5, next_event, bjunload, b_spots, travjtime, 

sb_obj, beach_obj) 

55; else if cur_task == 3 then 

56; process_b_event(next_event, bjunload, beach_obj) 

57; else 

58; process_return_to_sb(nea:i_cyeni, travjtime, beach_obj) 

59: end if 

60; end function 

61; function PROCESS_SB_EVENT(?iext_ef;e?it, sb_load, sb_obj) 

62: SAVE_coMPLETED_RUN > Before initializing next run, save previous run info 

63: arrivaljime <— next_event{\\ 

64; shipjd <— next_event{3^ 

65: next_spot <—get_next_free_sbspot(5&_o^7,> Whieh load spot next free 

66: time_spot_avail <—get_time_next_free_sbspot(5ft_oft7,> Time next spot free 

67: startjime <— max{arrival_time, time_spot_avail) > Time eonneetor starts loading 

68; splashjime <— startjime + sbJoad[shipJd] > Time eonneetor leaves ship 

69: next_event[2] 2 > New Connector task: leaving ship 

70; next_event[l] <— splashjime > New Connector time: departure from ship 

71: update_sb_object(5&_o&7, shipjd, splashjime) > Spot availahility, number of runs 

72; end function 
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73; function PROCESS_B_AssiGNMENT(Z>_rM?i5, next_event, b_unload, b_spots, trav_time) 

sb_obj, beach_obj > Additional function inputs 

74; assignjtime <— next_event\\\ 

75; ship_id <— next_event[3^ 

76; nextjbeach <— AssiGN_NEXT_BEACH(^_rMn5, beach_obj) > Which beach to go to 

77; beach_time <— assign_time + trav_time[ship_id][next_beach] > Time arrive at beach 
78; next_event[2] <— 3 > New Connector task; ready to unload at beach 

79; next_event[l] beach_time > New Connector time: arrive at beach 

80; next_event[6] <— nextjbeach > Store beach assigned to run 

81: next_event{5] <—ship_depart_run(5Z7_oZ>7, > Get run number 

82: vpoAT^_&B_OBmcY:{sb_obj,shipJd) > Number of runs 

83: uPDATE_BEACH_OBJECT(&efl;c/i_o& 7 , beach Jd) > Number of runs assigned to beach 

84; end function 

85; function PROCESS_B_EVENT(next_epent, b_unload, beach_obj) 

86: arrivalJime <— next_event[l] 

87; beachjd <— next_event\6\ 

88: next_spot ge.i_nextJx&e_b&^ot{beach_obj, beachjd) > Which load spot next free 

89; time_avail get Jime._ne\ljree Jospot{beach_obj, beach Jd) > Time next spot free 
90: start Jime <— max{arrivaljime, time_avail) > Time connector starts unloading 

91: splash_time <— start Jime + beach_unload[beachJd] > Time connector leaves beach 

92: next_event[2] <— 4 > New Connector task: returning to ship 

93: next_event{\\ splashjtime > New Connector time: departure from beach 

94: next_event{l] BBAcn_wj^_^vM{beach_obj,beach Jd) > Beach run number 

95: uPDATE_BEACH_OBJECT(Z>efl:c/i_o^ 7 , beachjd, splashjtime) > Spot availability, 

number of runs 

96; end function 
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97; function PROCESS_RETURN_TO_SB(?ie;cf_eye?if, trav_time, beach_obj) 

98; splashjime <— next_event{l\ 

99; ship_id <— next_event[3^ 

100; beach_id <— next_event\6\ 

101; returnjtime <— splash_time + trav_time[ship_id][beach_id] > Time back at ship 
102; next_event[2] <— 1 > New Connector task: ready to load at ship 

103: next_event[l] return_time > New Connector time: arrival back to ship 

104: update_beach_object( Z>eac/i_o^ 7 , beachjd) > One fewer connector at beach 

105; end function 

106; function ASSiGN_NEXT_BEACH(Z?_rMn5, beach_obj) 

107: max_deficit 0 > assign next run to beach with largest run deficit 

108: nextjbeach <- 1 > ID of next beach 

109; 

110: for i in l:num_beaches do 

111: tot_runs <— b_runs\i^ 

112: runs_assign beach_obi\i\\5\ 

113: cur_deficit <— tot_runs - runs_assign 

114: 

115; if cur_deficit > max_deficit then > Found new best candidate 

116: max_deficit <— cur_deficit 

117: nextjbeach <— i 

118: end if 

119: end for 

120; return bestjbeach 

121 : end function 


> Total runs required 
> Runs assigned to beach 
> Remaining runs 
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